Entity & identity
What is the unit of record, and how do we know it is the same one?
Every industry keeps records about one core thing, and has a rule for deciding that two records describe the same one. Get the rule wrong and every bill, report and audit downstream is quietly wrong too.
What it is
The entity is the noun the business can't function without: the account holder, the patient, the subscriber, the employee, the legal matter. Identity is the rule that decides the record in front of you today is the same one you saw last week, even after a name change, a merger, a new phone or a typo.
The hard part is almost never the entity. It's the identity rule, and who is allowed to override it.
Where you'll see it
| Industry | The entity | How identity gets decided |
|---|---|---|
| Payments | Account holder, merchant, card | Identity checks on people and businesses; a token stands in for the raw card number |
| Telco | Phone number, sender, brand | The number is an address, not a person; ownership is proven with documents and registrations |
| Healthcare | Patient | Matching on name, birth date and identifiers; a duplicate record is a safety risk |
| Payroll | Employee | Tax ID plus employment record; one person can hold two jobs at the same company |
| Legal | Client, matter | Conflict checks decide whether a "new" client is really an old adversary |
Questions to ask in week one
- What is the one record everything else hangs off?
- What makes two records the same one, and who decides when it's ambiguous?
- Can one real-world thing end up with two records, or one record cover two things? What breaks when it does?
- Which identifiers do we issue, and which are issued by someone else?
- What happens to the record when the real-world thing goes away?
The trap
Software PMs think of an ID as a primary key you mint. In regulated industries the identifier that matters is often issued by someone else (a tax authority, a numbering plan, a card network). You don't control the identity, you mirror it, and your data model has to survive the day the issuer changes its mind.
In the Field Guides
B2B payments: order to cash
The rail doesn't know your customer, and no single "customer" record does either. An ACH payment identifies the payer by routing and account number, not by legal entity or invoice. Upstream, "customer" splits into the legal entity that owes, sold-to, ship-to, bill-to and payer; credit limits sit at the parent while orders arrive per ship-to.
| Entity | Who issues the identity | Where it breaks |
|---|---|---|
| Seller | Its legal entities, each with its own remit-to account | Remit-to details must stay current; a factoring deal changes them |
| Payer | The seller's ERP customer master | A parent's shared-service center pays for all its subsidiaries at once |
| Credit account | The seller's credit team: limit, terms, risk class, guarantor | Limit set at the parent, orders per ship-to |
| Payer bank account | The payer's bank | A new "remit-from" account is the main reason cash goes unmatched |
| Order, shipment, proof of delivery | The seller's order system; the carrier | The evidence that wins or loses a deduction |
| Invoice, credit memo, deduction case | The seller's ERP and AR team; the payer adds its PO number | Deductions resolve against memos, not the invoice |
| Remit-to details | The seller | The attack surface for business email compromise (BEC) |
KYB: three populations
An AR fintech runs full KYB (know your business) on the sellers it onboards: legal entity, beneficial owners at 25% or more, a control person, sanctions. Payers get lighter checks: bank-account validation, fraud signals, sanctions. A seller granting terms has no statutory KYB duty (domestic US companies have been exempt from beneficial-ownership reporting since March 2025) but strict-liability sanctions exposure, and may pull a consumer report on a guarantor, not on an officer who isn't personally liable.
Name-to-account checks are voluntary in the US: the Fed announced a Payee Name Verification service in December 2025 (launch unconfirmed), and under UCC 4A-207 a bank may rely on the account number when name and number disagree.
The mapping from bank account to payer to credit account to invoice is yours to build and keep, and it's the asset that makes cash application and credit control work.
Sources: FinCEN rule summary (March 2025), OCC, sanctions screening.
Ask an expert: how often does a payer pay from an account you've never seen, and at what level (parent or subsidiary) do you set and enforce credit limits?
B2B payments: procure to pay
AP keeps more nouns apart than it looks like from outside:
| Entity | Who issues the identity | Where it breaks |
|---|---|---|
| Supplier (legal entity) | Tax authorities: a TIN certified on Form W-9 (US); a Business Number and GST/HST registration (Canada) | The invoice name doesn't match the tax record |
| Vendor record | The buyer's ERP vendor master | One supplier, several records: a duplicate-payment and fraud risk. Records also cover employees, tax authorities and refunds |
| Remit-to and bank account | The supplier, through the buyer's change process | The attack surface for business email compromise (BEC) |
| Buying entity | The buyer's own legal entities, often many | An invoice addressed to the wrong entity is rejected |
| Invoice, credit memo | The supplier | A re-sent or renumbered invoice becomes a duplicate |
Is the supplier real?
In the US, the W-9 certifies the supplier's taxpayer identification number under penalties of perjury. The IRS's free TIN Matching service checks up to 25 name and number pairs instantly, or 100,000 in bulk within 24 hours; a missing or wrong number triggers 24% backup withholding (IRS, Oct 2026). Canada has no W-9: AP collects the Business Number and checks the GST/HST number in the CRA registry, keeping the result as evidence for tax credits.
Is the account theirs?
No Nacha rule requires a buyer to validate a supplier's account before sending an ACH credit. Nacha's December 2025 tips recommend it anyway, plus verifying change requests out of band with contact details already on file, and dual control. The Fed announced a Payee Name Verification service in December 2025 (launch date unconfirmed). Meanwhile UCC 4A-207 lets the receiving bank rely on the account number when name and number disagree.
A supplier's identity is issued by tax authorities and banks, not by you, and the bank account is the field a fraudster most wants to change.
Ask an expert: what share of vendor records at a mid-market buyer are inactive or duplicates, and how many bank-detail change requests arrive in a month?
B2B payments: spend management
Each card carries three identities, and each expense adds two more.
| Entity | Who issues the identity | Where it breaks |
|---|---|---|
| Legal issuer | The sponsor bank, as BIN licensee and creditor | The brand on the card isn't the issuer |
| Company (account) | The bank's KYB, done by the program manager: owners of 25% or more, a control person | Refresh is a bank duty pushed onto the fintech |
| Employee cardholder | The company's HR records | Leavers keep cards; work state and province drive tax and labor rules |
| Merchant | The acquirer assigns the category code; the name is cut to 25 characters | The code describes the merchant, not the item |
| Receipt issuer | The merchant's own name and, in Canada, its GST/HST number | The receipt name doesn't match the card descriptor |
Reg Z counts organizations as cardholders, so on a corporate account the company is the cardholder. The employee becomes a debtor only under individual liability ("the cardholder will be solely liable", in Mastercard's definitions) or joint liability, and then needs a credit check. The employee's attributes still drive rules under every model: work state, province (which HST factor), Quebec (a second tax slip), owning 10% or more of the company (no lodging per diem for related parties), and a federally regulated Canadian employer (a 30-day reimbursement rule).
Visa's merchant data standards have the acquirer assign the code for the merchant's primary business, cut the name to 25 characters, and let marketplaces use one code (5262) for everything they sell. The network knows roughly who was paid; it never knows what was bought. US companies no longer report beneficial owners to FinCEN (since March 2025), but banks must still collect them, and sponsor banks push that work onto the program manager.
Sources: Reg Z interpretation, Visa Merchant Data Standards Manual (April 2026), Rev. Proc. 2019-48, FinCEN; Mastercard's definitions via a US bank's brochure (undated).
The bank issues the card, the company owes for it, the employee carries it, and the merchant is a 25-character string: model all four, because each answers a different question.
Ask an expert: for KYB refresh, employee sanctions screening and beneficial-owner changes, who is the customer of record: us, the bank, or both?
Telco: numbers and senders
Three nouns get conflated constantly: the number (an E.164 address, the ITU format of country code plus national number, allocated to a carrier and reaching you through resale), the sender (whatever the recipient sees) and the business (the legal entity a gatekeeper has checked). Keep them apart in your data model.
| Sender | Unit of identity | What proves it |
|---|---|---|
| 10DLC | Brand → campaign → numbers (one campaign per number) | TCR matches legal name, EIN and address to official records; Auth+ emails a named representative (public companies, since Aug 2025); optional vet score |
| Toll-free | Each number | Verification, with a business registration number required for new submissions since early 2026 |
| Short code | Each program, per carrier | Registry vetting (name, tax ID, legal history), then each carrier's review |
| Alpha abroad | Sender ID × country × carrier | Proof of the brand link: India registers entity, header, template and consent; Spain wants a trademark, trade name or domain |
| RCS | Agent, owned by the platform as Google's partner | The brand's contact answers Google's verification email, once per agent |
| Portfolio → WABA → number → display name | Meta business verification, display name review | |
| Voice | The number on the call | The signing provider's STIR/SHAKEN attestation |
Sources: TCR fees, TCR Auth+ 2.0, CNMC, TRAI, Google brand verification; the toll-free and sole proprietor details come from provider notices (secondary).
Two definitions to know cold. A 10DLC sole proprietor is a person or business without an EIN (an LLC with one isn't), verified by a one-time code to a US or Canadian mobile; providers report a limit of one campaign and one number. And Auth+, today required only of public companies, is reported by providers to extend to new brands of every type except sole proprietors from January 21, 2027.
The identity that matters is issued and checked by someone else, at a different level for every sender type. Model brand, campaign, sender and number as separate records, each with its own history.
Ask an expert: what share of brand and toll-free verification rejections trace to identity data (legal name, EIN, address, website) rather than the use case, and which field breaks most often?
Field Guides are learning notes, not legal or compliance advice. Rules and fees change; check the cited primary sources before you act on anything here.