Customers

A customer is a contact you sell to. In Solid Accounting, customers, vendors, and employees all live in a single contacts table — what differs is the contact_type field. This page covers the customer side: setting them up, the fields that drive default behavior on invoices, and how customer history surfaces in reports.

For the AR-side mechanics (invoices, payments, aging, statements), see Accounts Receivable.

Customer fields

Every customer record stores:

A customer can also be a vendor. Set contact_type accordingly — Solid stores both flags. Common in co-ops, franchise models, or anywhere you trade both directions with the same party.

Adding a customer

Three paths:

1. Lists → Customers → New — full form
2. Inline from the invoice form — + New customer button next to the customer dropdown when writing an invoice. Pops a smaller form, returns to the invoice with the new customer selected.
3. Bulk import — CSV import from settings (one row per customer; standard column mapping wizard) or pulled from a migration source like QuickBooks Online or Xero.

Most users add customers as needed via the inline path — full bulk-import is for one-time migrations.

Custom fields

Customers support arbitrary custom fields stored as JSON in the custom_fields column. Common uses:

• Customer ID from your CRM — store the cross-system identifier so integrations can match
• Account manager — internal owner
• Industry — segmentation for reporting

Custom fields are configurable per file under settings; once defined, they appear on the customer form and can be used to filter reports.

Multi-currency customers

Setting a customer's currency to anything other than your file's base currency makes that customer "foreign-currency":

• New invoices to them default to that currency
• Exchange rates are captured at invoice issuance time and stored on the invoice
• Reports translate to base currency at the stored historical rate (so prior reports stay reproducible)
• When the customer pays, FX gain/loss between issue date and pay date posts to a configured FX account

See General Ledger → Multi-currency for the broader picture.

Customer statements

A statement is a chronological summary of activity for one customer in a period:

Statement for Acme Corp — period: April 2026

  Opening balance              4,200.00
  04/05  Invoice 1042          1,800.00
  04/12  Invoice 1051          2,500.00
  04/18  Payment received     -3,000.00
  04/29  Invoice 1063            900.00
  ────────────────────────────────────
  Closing balance              6,400.00

Generated from the customer's transaction history in the GL — there's no separate statement table. PDF and email-friendly format are the two main delivery paths.

Statements ignore voided transactions for the cosmetic view; the underlying audit log retains them. Customers see what they care about: what they were billed, what they paid, what they owe.

Reports involving customers

All export to PDF and CSV.

Inactivating customers

Mark a customer inactive when:

• They're no longer a customer
• They were imported in bulk and aren't actually buying from you
• You want to declutter the picker but preserve historical records

Inactive customers:

• Don't appear in invoice/estimate pickers
• Don't show on the default Customer List (filterable to include them)
• Their historical invoices, payments, and statements remain
• AR Aging and Sales by Customer reports include them with a clear inactive marker

You can reactivate at any time. The active flag is just a UI/picker filter — it doesn't delete or anonymize.

TIN encryption

The TIN field uses AES-256 encryption at rest. The encryption key is derived from the file's master password, so:

• A file without the correct password can't decrypt TINs (along with everything else in a .solid file)
• TIN access is logged in the audit trail (a deliberate choice — viewing tax IDs is a sensitive operation)
• The UI shows masked TINs (***-**-1234) by default; full reveal requires an Admin's password re-entry

For 1099 reporting, Solid decrypts TINs at report time only — they don't sit in cleartext anywhere except the running process's memory during report generation.

Common gotchas

Display name conflicts with another customer. Solid allows duplicate display names but warns at create time. Common when migrating — two customers both named "Smith Inc" from different states. Differentiate via the company name + city.

Currency on the customer doesn't match invoice currency. Customer currency is a default; the invoice's currency wins. To force a customer to always invoice in one currency, edit the customer record — or override per invoice if it's a one-off.

Deleted a customer accidentally. Customers with transaction history can't be hard-deleted (Solid blocks it). Mark inactive instead. If you really did hard-delete a customer with no history, restore from a backup.

Customer balance shows non-zero but no open invoices. Almost always an unapplied payment or credit memo. Drill into the customer's transaction history; one entry will be uncleared at the bottom.

Custom field doesn't appear on a particular customer. Custom fields are file-level — they apply to all customers in the file. If one customer doesn't show the field, the field probably wasn't defined when that customer was created (it was added later). Editing the customer should pull in the new field as blank.

Cross-references

• Accounts Receivable module — invoices, payments, aging
• Estimates module — quotes that precede invoices
• Vendors module — the AP-side analog
• Reports → Sales by Customer — revenue analysis