Fields That Are Not on Your Customer Record
Your customer master records what you need to know about a customer. It has nowhere to record what your customer asserts about themselves — and in some markets the document will not clear without it.
Open the customer record in any accounting or operations system and look at what is on it. A name. An address. Payment terms, a credit limit, a contact, a tax registration number. Perhaps a category, a price list, a salesperson.
Every one of those fields exists because the seller needs it. That is not a criticism — it is what a customer master is for. You are recording the things you must know in order to trade with somebody.
What is almost never there is a field for something the buyer declares about their own position: how they are classified for tax purposes, or what they intend a receipt to be used for. In most markets nothing asks, so nothing stores it. When a market does ask, you do not have a wrong value. You have no field — and a missing field cannot be defaulted, guessed, or put in the notes.
Mexico is where our own model runs out
Two attributes, and neither exists in our product: a fiscal-regime attribute on the customer, and a use-of-receipt attribute on the document. The market page states both plainly in its honesty ledger rather than leaving them to be discovered.
What makes them interesting rather than merely absent is whose facts they are. A tax registration number is a fact about your customer that you can look up and verify. These are assertions your customer makes about themselves — and the value can differ between two transactions with the same customer, because the second one is for a different purpose.
The sentence worth keeping from this whole post
You are not the right person to decide these values, and neither is your software. They are your customer's declaration about their own affairs. Which means the operational requirement is not "compute it" — it is capture what they told you, and be able to show that you captured it. Any vendor offering to derive one of these from your customer's address or industry is offering to invent a fact on somebody else's behalf.
Why "put it in the notes" fails, specifically
It is the universal workaround and it fails in four ways at once — worth spelling out, because it always sounds reasonable in the meeting where it is proposed.
| What goes wrong | Why |
|---|---|
| It cannot be sent | A downstream system needs a value in a field. A notes field is not a field it reads |
| It cannot vary per document | A note on the customer is one value. The use of a receipt can differ per transaction |
| It cannot be validated | Nothing checks a note, so a stale or mistyped value survives indefinitely |
| It cannot be reported | "Show me every transaction where the customer declared X" is not answerable from free text |
A note records that somebody once knew something. A field records it in a way the next person, and the next system, can act on.
The general shape, which is not about Mexico
Once you notice this class of field, it turns up everywhere. Anywhere a counterparty's own declared status changes how you must treat a transaction, you need somewhere to hold the declaration and evidence of when it was made.
-
A declared tax position
The buyer states how they are classified, and the treatment of the document follows from it. Mexico is the case in this corpus.
-
A declared purpose for a purchase
The same goods, to the same customer, treated differently because of what they are for. The value belongs to the transaction and not to the customer.
-
A registration status that lapses
In some markets what you must charge depends on whether the buyer's registration is currently active — a fact about them, changing without notice, and one you are nonetheless expected to reflect.
-
An exemption certificate
A document the buyer supplies asserting their own status. Evidence and expiry, held against the counterparty, and rarely modelled as anything other than an attachment.
The common failure across all four is identical: the system models what you know and not what you were told. And when a question arrives later, "what did they tell us, and when" is the only version of the answer that is worth anything.
Where we stand
One record per counterparty with its identifiers
Registration numbers, addresses and identifiers held on the party rather than scattered across a delivery note, an accounting system and somebody's inbox.
Documents held against the counterparty, with expiry dates watched
Which is the honest partial answer available today: where a customer supplies a document asserting their status, it can be held against them with a date the system tracks. Not a field, but not nothing.
A fiscal-regime attribute on the customer
Not built. No field, so no value and no output. Ordinary work — a field, a validated list, a default, a migration — and commissionable with a written specification, a timeline and a price.
A use-of-receipt attribute on the document
Not built, and the harder of the two conceptually rather than technically: it belongs to the transaction rather than to the customer, so it cannot be solved by adding one field to the customer master. Also commissionable.
Deciding either value for you
Not ours, ever. These are your customer's declarations about their own affairs. We can capture and evidence what you were told. Inferring it would be inventing a fact on a third party's behalf, and it would look exactly like a feature right up until it mattered.
What is built here, what is not, and what we would decline is on the Mexico market page, which is candid that the invoice in this market is cleared before your customer sees it and that ours is a printed representation. The item-record version of the same pressure is a catalogue is not a text field; the document-lifecycle version is a cancellation your customer can refuse.
