Customer

A customer is a party that has an established commercial relationship with a business and can be billed for goods or services.

Also called Account · Buyer · Client · Debtor · Party

Why it exists

Because a business needs one place to answer "who owes us money, and can they have more credit?" Every other sales object hangs off that question.

What it means to the business

The customer record is the spine of receivables. It is the thing credit limits attach to, the thing ageing reports group by, and the thing a salesperson checks before promising a delivery date. When it fragments into duplicates, all three stop being trustworthy at once — and the symptom people notice first is usually not the duplicates, it is that the ageing report stops matching the bank.

01Lifecycle — walk the states

Lead. Interest exists; no commercial relationship yet. Not billable.

State 1 of 4

02Relationships — walk the chain

Customer has Contact.

One or many people. A person, not a billing party.

Open Contact
03What goes wrong — and why
  • Receivables fragment across duplicates, credit limits stop working, and the same buyer appears three times in every report. Almost always the single largest data-quality problem in a migration.

Rules that must hold

  • A customer must be billable — it needs a legal name and, in India, a GSTIN if registered.
  • A customer is not the same object as a contact: a contact is a person, a customer is a billing party.
  • Deleting a customer with posted transactions must be impossible; deactivation is the only correct operation.

What commonly goes wrong

Duplicates, almost every time, and they are created by well-meaning people: a rep who cannot find the existing record makes a new one, and the credit limit silently resets. The fix is not training, it is a search that works and a uniqueness rule at the point of entry.

Edge cases

  • A buyer who is also a supplier — the same legal entity needs both a Customer and a Supplier record, and netting between them is a manual decision, not automatic.
  • Multi-GSTIN buyers: one legal name, several registrations, each requiring its own place-of-supply treatment.
  • Consumer sales with no registration at all, where the invoice is B2C and the reporting threshold differs.

How ERPNext models it

DocTypeNote
CustomerThe billing party. `customer_group` is for pricing/reporting, not legal structure.
ContactLinked via Dynamic Link, not a field on Customer — which is why one contact can serve several parties.
AddressAlso a Dynamic Link. `is_primary_address` and `is_shipping_address` are separate flags.

Last reviewed 2026-08-13

Machine-readable version

We implement this for a living — that’s where the mistakes above come from. See the service or request a discovery briefing