Contacts

Adding and Managing Contacts

What contacts are for A contact is anyone your business does transactions with. Customers, vendors, employees, lenders, anyone outside your company who appears in a transaction. You attach a contact to most transactions so you can later answer questions like: - How much revenue did I get from each customer this year? - How much did I pay each vendor? - Who am I owed money by? (Outstanding receivables.) - Who do I owe money to? (Outstanding payables.) Without contacts, the books are anonymous. With them, you can drill into any number and see who. How to create a contact Two ways: From the Contacts page 1. Click Admin in the sidebar 2. Click the Contacts tab 3. Click New Contact 4. Fill in the form 5. Save On the fly during a transaction Inside the New Transaction modal, the contact picker has an + Add new contact option at the bottom. Click it, fill in the new contact's details inline, save, and the new contact is selected for the transaction without ever leaving the form. This is faster when you're entering a transaction with a customer who isn't in the system yet. Contact picker dropdown showing autocomplete with "+ Add new contact" at the bottom The contact form Fields: | Field | Required? | Notes | |---|---|---| | Name | Yes | Their business name or personal name | | Kind | Yes | Customer / Vendor / Employee / Other (see Customers, Vendors, Employees, Other) | | Email | No | Used for sending invoices and notifications | | Phone | No | Reference, not auto-dialed | | Street address | No | For invoices and tax reporting | | City, state, country, zip | No | Same | | Nostr public key | No | If they have one (Bitcoin businesses use this) | The Name + Kind combination must be unique within an organization. You can have a "Acme Corp" customer and an "Acme Corp" vendor (different kinds). You can't have two "Acme Corp" customers. Linking contacts to transactions When you create a transaction (Simple Mode or Advanced Mode), one of the fields is Contact. Type to search; pick from the dropdown. For one-off cash sales where the individual customer isn't tracked, use a generic contact like "Cash Customer" or "Walk-in Customer." Many businesses create one or two of these and reuse them. For recurring vendors (your landlord, your software providers), creating proper contacts is worth it: every transaction with them becomes searchable, and a "Spend by Vendor" view becomes useful. Managing contacts The Contacts page (Admin → Contacts) lists every contact: - Name - Kind - Email and phone - Address summary Contacts table on the Admin page You can: - Click a contact to view detail and recent transactions - Edit any field - Archive (don't delete) when you no longer want them appearing in dropdowns - Filter by kind (just customers, just vendors) Searching for transactions by contact Two ways: From the contact's detail page Open the contact. The detail page shows their recent transactions automatically. From the Transactions page Use the contact filter on the Transactions page to show only entries linked to a specific contact. From the General Ledger Filter the GL by contact. Useful when you want detailed accounting (debits and credits) per contact. Bulk import If you're migrating from another tool, you can import contacts in bulk: - From QuickBooks: the QuickBooks importer brings over contacts as part of the migration - From CSV: upload a CSV with name, kind, email, phone, address. BitBooks creates contacts from the rows. For one-time setup, bulk import is much faster than creating one at a time. See Importing Contacts from QuickBooks. Archiving a contact If you stop doing business with someone (a former customer, a closed vendor relationship): 1. Open the contact 2. Click Archive Archived contacts: - Disappear from the Contacts list (toggle "Show archived" to see them) - Don't appear in dropdowns when creating new transactions - Keep their historical transactions linked (no data loss) - Can be restored Don't delete contacts. Always archive. Deletion would orphan past transactions. Contact-related fields on transactions Some transactions have additional contact-related fields: - To/From address. A Bitcoin address or wallet identifier where the transaction went or came from. Distinct from the contact themselves. - Reference number. Your internal reference, often an invoice number or order number. - Memo. Free text. Anything that helps identify the transaction later. The contact field is the "who." The other fields are the "what" and "when" specifics. A worked example A new vendor named "Acme Lightning Hosting" sends you a $500 monthly bill. Setup: 1. Create the contact: name "Acme Lightning Hosting," kind "Vendor," email "billing@acmelightning.com" Each month: 1. Create a new Transaction in Simple Mode 2. Wallet: Company Credit Card 3. Direction: Money out 4. Amount: $500 5. Contact: Acme Lightning Hosting (autocompletes from the dropdown) 6. Category: Software Subscriptions 7. Memo: Invoice number from their bill 8. Save and post Year-end: 1. Open Acme Lightning Hosting's contact page 2. See all 12 monthly transactions, totaling $6,000 Or run the General Ledger filtered by Acme Lightning Hosting and you have the same view. Common questions "Do I need to create a contact for every transaction?" Not strictly. The contact field is optional. But: - For revenue, contacts let you analyze customer concentration ("Are 80% of my sales from one customer?") - For expenses, contacts let you analyze vendor spend - For tax season, contacts make it easier to issue 1099s (in jurisdictions where that applies) The investment to set up contacts pays off in clarity. Most teams use them for any recurring counterparty and skip them for one-off cash transactions. "Can a contact be both a customer and a vendor?" Yes, but they'd be two separate contacts (one with kind=Customer, one with kind=Vendor). The Contact form treats Kind as distinguishing. "What if I get a customer's name wrong?" Edit the contact (Admin → Contacts → click → Edit → save). The new name applies everywhere they're referenced. Past transactions automatically show the updated name. Where to go next - Customers, Vendors, Employees, Other for the kind distinctions - Linking Contacts to Transactions for the transaction-side mechanics - Importing Contacts from QuickBooks for migration - Creating a Transaction (Simple Mode) for the standard transaction flow

Customers, Vendors, Employees, Other

What "kind" means on a contact When you create a contact, BitBooks asks for a kind (a category). Four options: - Customer - Vendor - Employee - Other The kind is metadata. It doesn't change much functionally, but it affects: - Filtering and grouping in the Contacts list - Default behavior in some flows (e.g., sales transactions default to Customer contacts) - Reports that segment by counterparty type - Tax reporting templates (a 1099 form, for example, is for non-employee individuals you paid) Pick the kind that best describes the relationship. Customer Anyone who pays you for a product or service. The other side of your sales transactions. Examples: - A retail customer paying for coffee - A consulting client paying for hours - A subscriber paying a monthly fee - Another business that bought from you For one-off cash sales where you don't track individuals, you can create a generic "Cash Customer" or "Walk-in Customer" contact and reuse it. That works fine for a coffee shop. Vendor Anyone you pay for a product or service. The other side of your expense transactions. Examples: - Your landlord - Your software providers (Slack, AWS, Adobe, etc.) - Your accountant - A contractor who did one-off work - A supplier of inventory or raw materials For one-off cash purchases (e.g., a meal at a random restaurant), you can skip creating a contact or use a generic "Misc Vendor." Employee People you employ. Examples: - W-2 employees in the US - Salaried staff - Hourly staff Why a separate kind? In some jurisdictions, payments to employees flow through a payroll system (taxes, benefits, etc.) and the accounting is different from vendor payments. BitBooks doesn't do payroll itself. If you're paying employees, the typical pattern is: - Run payroll through a separate system (Gusto, Wagepoint, etc.) - Each pay period, post a journal entry in BitBooks summarizing payroll: salaries expense, payroll tax expense, cash out - Each employee can be a contact (kind = Employee) so individual payment records stay clean Other Anyone who doesn't fit the above three. Examples: - A lender (someone you've borrowed from). Their loan principal repayments aren't really an "expense"; they reduce a liability. Use kind = Other. - An owner or shareholder. Their capital contributions and dividends aren't sales or expenses; they're equity events. Use Other. - A government tax authority. Tax payments aren't an "expense" in the normal sense; they're a separate flow. Use Other. - Anyone who spans roles or doesn't have a clean categorization. A few edge cases Contractor vs Employee In some jurisdictions, the distinction between contractor and employee is legally significant (different tax forms, different benefit obligations). In BitBooks, an independent contractor is typically Vendor kind. They're an outside party you pay for services; they handle their own taxes. An employee is Employee kind. Different tax forms. If you're unsure (it's a gray-area worker), talk to your accountant. The kind in BitBooks doesn't determine tax treatment; the underlying relationship does. Customer who is also a vendor Some businesses have counterparts who appear on both sides. For example, a Bitcoin exchange that you both buy from (vendor) and sell to (customer). Best practice: create two contacts. "Coinbase (Vendor)" for purchases and "Coinbase (Customer)" for sales. Each kind drives different reports cleanly. Same person across organizations If you manage multiple BitBooks organizations and the same person appears in several, each org has its own contact list. There's no shared contact pool. You'd create the contact in each org as needed. What you can change later Most contact fields are editable any time: - Name (changes propagate everywhere) - Email, phone, address - Memo The kind is harder to change after the contact has been used in transactions. Changing kind from Customer to Vendor would re-classify all the historical transactions that used this contact, which can be confusing. If you really need to change kind, the cleanest path is: archive the original contact, create a new one with the right kind, and update past transactions to reference the new one (or leave history as-is). Reports that use the kind A few places where the kind affects the view: - The Contacts page lets you filter by kind - Some reports (e.g., a future "Spend by Vendor" or "Sales by Customer" view, when shipped) segment by kind - Tax-export templates (e.g., 1099 prep) target Vendor and Employee kinds specifically For most everyday work, the kind is mostly informational. Pick correctly at creation; you'll mostly forget it after that. Common questions "What if a contact's role changes (was a customer, now they're a vendor)?" Best practice: leave the original contact, create a new one for the new role. They'll show as two contacts because they really are playing two roles. "Do I have to pick a kind?" Yes, but Other is always valid if nothing else fits. The kind is required because reports group by it. "Can I have hundreds of contacts?" Yes. BitBooks handles large contact lists. The Contacts page paginates and supports search. Where to go next - Adding and Managing Contacts for the create/edit walkthrough - Linking Contacts to Transactions for the transaction-side mechanics - Importing Contacts from QuickBooks for bulk import - Tax & Compliance for how Employee and Vendor kinds interact with tax filings

Linking Contacts to Transactions

The basic flow Most transactions have a Contact field. When you create or edit a transaction (Simple Mode or Advanced Mode), you pick a contact from the dropdown. Linking the contact: - Saves the contact ID with the transaction - Lets you later filter transactions by contact - Lets you see "all transactions for this contact" from the contact's detail page - Powers reports that segment by contact For most transactions, picking the contact takes one click (the dropdown autocompletes from your contact list). How the picker works The contact field is a search-as-you-type dropdown: 1. Click the field to open 2. Start typing the contact's name 3. The dropdown narrows to matches 4. Click the right contact If the contact doesn't exist yet, the dropdown shows + Add new contact at the bottom. Click it to create a new contact inline without leaving the transaction form. Contact picker dropdown open with autocomplete results and the "Add new contact" option visible When the contact field is optional For some transactions, no contact is involved: - Wallet-to-wallet transfers (it's between your own wallets, no third party) - Closing entries (internal accounting only) - Depreciation entries (internal, no party) - FX revaluation entries (internal) For these, leave the contact blank. BitBooks doesn't require it. For all other transactions (sales, expenses, payments), the contact is technically optional but strongly recommended. A transaction without a contact loses the "who" detail. Linking on Simple Mode (Transactions page) The New Transaction modal has a contact field. Same picker behavior. For Standard mode (one wallet), one contact applies to the whole transaction. For Split mode (one wallet, multiple line categories), one contact applies; you can't have different contacts per line in Split mode. For Transfer mode (between your own wallets), the contact field is hidden (transfers don't have an external party). Linking on Advanced Mode (Journal Entries) In Advanced Mode, each line of a journal entry can have its own contact. Most multi-line entries don't need this; one contact applies to all lines. But for some entries (e.g., a wire that paid two different vendors), per-line contacts make sense. The journal entry header doesn't have a contact field; only the lines do. Reports that segment by contact use the line-level contact. Linking on auto-imported transactions When auto-sync imports transactions from a wallet provider, the Contact field is usually blank. Wallet providers rarely know who the counterparty is (a Lightning payment doesn't include "from John Smith"; it's just "5,000 sats came in"). You fill in the contact during the review-and-post step. For high-volume Lightning operations where most receives are one-off retail customers, you'd typically use a generic contact (e.g., "Cash Customer") for all of them. You don't need to track individual coffee buyers. For B2B Lightning payments where the counterparty matters, you'd identify them from the memo or invoice number and pick the proper contact. Searching transactions by contact Three places to find all transactions for a contact: From the contact's detail page Open Admin → Contacts → click the contact. The detail page lists their recent transactions automatically. From the Transactions page Use the contact filter in the filter bar. Pick a contact; the table shows only their transactions. From the General Ledger Filter the GL by contact. Useful when you want full accounting detail (debits and credits) for one party. Changing a contact on a posted transaction Posted transactions are mostly locked, but the contact field is one of the editable fields on a Posted transaction. You can re-link to a different contact without reversing. Why? Contacts are metadata, not numbers. Changing the contact doesn't affect the financial impact of the transaction. So BitBooks allows it for clean-up purposes. To change: open the transaction, click Edit, change the contact, save. The change is logged in the Activity Log. Common patterns Walk-in retail / coffee shop Use a generic "Cash Customer" or "Walk-in Customer" for all sales. Don't try to track individual coffee buyers. The number of transactions per individual customer is too low to be useful. For loyalty program members or B2B accounts, create proper contacts. Consulting / freelance Track each client as a Customer contact. Use the contact filter to bill correctly and to analyze customer concentration ("Are 70% of my fees from one client?"). E-commerce For one-off online retail, generic "Online Customer" can suffice. For repeat customers or B2B accounts, individual contacts make sense. B2B services Always link contacts. Customer-by-customer revenue analysis is a key business metric. Vendor relationships Always link contacts for recurring vendors. "Spend by Vendor" is a key cost-management view. Reports that use contact data Today: - Contact detail page shows recent transactions - Transactions / Journal Entries pages support contact filtering - General Ledger supports contact filtering Soon (roadmap): - A Sales by Customer report (revenue grouped by Customer contact) - A Spend by Vendor report (expenses grouped by Vendor contact) - A Customer aging report (outstanding receivables by customer) - A Vendor aging report (outstanding payables by vendor) These will become standard reports. For now, the GL with contact filter approximates them. Common questions "My auto-import showed up with no contact. Should I leave it blank or pick something generic?" Pick something. Even a generic "Cash Customer" beats blank. Blank-contact transactions are harder to drill into later. "What if I picked the wrong contact and the transaction is Posted?" You can edit the contact on a Posted transaction (it's one of the editable metadata fields). Just open and change. "Can a transaction have multiple contacts?" Not directly on a single Standard transaction. In Split mode, no. In Advanced Mode (Journal Entries), yes: each line can have its own contact. For complex cases where multiple parties are involved (a payment processed through an intermediary), use Advanced Mode with per-line contacts, or split the transaction across lines. Where to go next - Adding and Managing Contacts for create/edit - Customers, Vendors, Employees, Other for the kind distinctions - Importing Contacts from QuickBooks for migration - General Ledger for transaction detail filtered by contact

Importing Contacts from QuickBooks

What gets imported The QuickBooks importer brings over your existing contacts as part of a broader migration. Specifically: - Customer list: every customer record with name, email, phone, address - Vendor list: every vendor record with the same fields - Employee list: if you tracked employees in QuickBooks, they come over too Contacts in BitBooks have the same fields as the corresponding QuickBooks lists, so the mapping is direct. What doesn't import A few things don't translate cleanly: - Custom fields. QuickBooks lets you create custom fields per customer (e.g., "Customer Tier" or "Internal ID"). BitBooks doesn't have customer-side custom fields yet. The data isn't lost; you can put it in the Memo field per contact, but you'd do this manually. - Notes attached to contacts. QuickBooks has free-text notes; BitBooks contacts have an internal description. Long notes might get truncated or formatted differently. - Subaccount or sub-customer hierarchies. QuickBooks supports nesting customers under parent accounts. BitBooks contacts are flat. Hierarchies don't preserve. For most small businesses, none of these are deal-breakers. You'll have your customer and vendor lists in BitBooks with the essentials. How to start the import 1. Admin → Imports (or look for "Import from QuickBooks" in the admin section) 2. Click Start Import 3. Pick the source: QuickBooks Online or QuickBooks Desktop 4. Follow the prompts (file upload for Desktop, OAuth for Online) 5. Review the staged data 6. Commit QuickBooks Import flow showing source selection and the upload step QuickBooks Online (OAuth) For QuickBooks Online, BitBooks connects via OAuth: 1. Click Connect to QuickBooks Online 2. Sign in to your QuickBooks account in the popup 3. Grant BitBooks permission to read your data 4. The popup closes 5. BitBooks downloads your customer, vendor, and employee lists in the background For more on what permissions BitBooks asks for, see the QB Online docs the popup links to. QuickBooks Desktop (file export) For QuickBooks Desktop, you export your data and upload: 1. In QuickBooks Desktop: File → Utilities → Export → Lists to IIF or generate an Excel export of your customer/vendor lists 2. In BitBooks: pick QuickBooks Desktop, upload the IIF/Excel file 3. BitBooks parses and stages The exact export format varies by QuickBooks Desktop version. If your file isn't accepted, check the file format documentation or contact support with the file in hand. Reviewing the staged data After upload (or OAuth fetch), BitBooks shows you the contacts that would be created: - Customers: N records - Vendors: N records - Employees: N records You can: - Review a sample. Spot-check a few contacts for accuracy. - Drop duplicates. If a contact already exists in BitBooks (from prior partial migration or manual creation), the importer flags potential duplicates and lets you skip them. - Adjust kind. Most contacts come over with the right kind (Customer, Vendor, Employee). For odd cases, you can override before import. Import review screen showing the count of staged contacts and a sample table When the staged data looks right, click Commit Import. After committing BitBooks creates the contacts in your organization. You'll see them in Admin → Contacts immediately. Future transactions can reference them via the Contact field. Past transactions (if you also imported transactions) get linked to contacts during the transaction-import phase. Re-running the import If you partially migrated (just contacts, not transactions yet) and want to redo, re-running the import: - Compares against existing contacts (by name + kind) - Skips duplicates - Adds any new contacts that have appeared at QB since the last import You can re-run safely without creating duplicates. The dedupe logic uses name + kind as the key. What to do after the contact import Common next steps: 1. Review the imported contacts for accuracy. Spot-check a few names, emails, addresses. 2. Set up generic contacts for catch-all use (e.g., "Cash Customer," "Misc Vendor") if you don't already have them. 3. Archive any imported contacts you don't need (defunct vendors, lost customers). 4. Import transactions as a separate step if you haven't yet. Past transactions reference contacts; that's why contact import comes first. For the broader QuickBooks migration, see BitBooks vs QuickBooks. Common questions "My QuickBooks has 1,500 customers. Will the import handle that?" Yes. Up to several thousand contacts works fine. Beyond that, performance gets slower; talk to support if you have an unusually large list. "My contact names have special characters (accented letters, etc.). Will they import correctly?" Yes. UTF-8 throughout. Accents, non-Latin characters, all preserved. "Some QuickBooks customers have hundreds of fields filled in (custom fields, notes, sub-customers). Do I lose all that?" Custom fields and sub-customer hierarchies don't import. Notes go into a description field if it fits. The core fields (name, email, phone, address) preserve. For the lost data, you'd manually copy what matters into BitBooks fields. "Can I import contacts without importing transactions?" Yes. Contacts are a separate step. You can import contacts now and import transactions later, or never (if you want to start fresh on transactions). Where to go next - Adding and Managing Contacts for the manual create/edit flow - Customers, Vendors, Employees, Other for the kind distinctions - BitBooks vs QuickBooks for the broader migration story - Linking Contacts to Transactions for using contacts after import