Where invoice data actually breaks

Invoice data breaks at handoffs: the points where information passes from one person, team or system to another before an invoice is raised. Six of them recur in almost every business that invoices other businesses. Customer records, order references, prices, reference formats, discounts agreed off the system, and credit notes issued to repair errors nobody traced.

None of the six is a software fault. Each is a place where the information an invoice depends on was created by one party, used by another and checked by neither, and where a capable person now corrects it on the way past.

The six handoffs

• Customer creation. Someone types a new customer rather than selecting an existing one, and the business now holds two records for one buyer, each of them partly right.
• Order to invoice. The buyer's purchase order number arrives after the invoice has gone out, or never arrives, and the invoice waits in the buyer's approval queue until someone amends it.
• Price list to system. The agreed price lives in a spreadsheet or an email and is copied into the invoicing system by hand, on a schedule, by whoever remembers.
• Counterparty to matching. A customer changes the format of its references and tells nobody, so a person learns to recognise the new format and corrects it every time it appears.
• Sales call to billing. A discount agreed in conversation is applied by hand at invoicing, from memory or from a note, and the reason for it is recorded nowhere the invoice can see.
• Collections to billing. A credit note is issued to settle a dispute, the dispute is closed, and the error that caused it is never traced back to whichever of the other five produced it.

Each of these was survivable while an invoice could be corrected after it left. Under the mandate, several of the fields these handoffs feed become mandatory and are validated before the invoice is delivered, which turns a set of inconveniences into a set of constraints.

Why none of them looks like a problem

None of the six produces an error message. Each produces a small correction, made by someone competent, inside another task. The customer who exists twice is merged at month end. The missing reference is chased by email. The wrong price is fixed with a credit note. The work gets done, the invoice is eventually paid, and nothing in any report records that it happened.

That is what makes invoice data quality so hard to fund. A problem that appears on no report has no owner and no budget, and the person absorbing it has usually stopped noticing it as a separate job. Asked how invoicing is going, they will truthfully say it is fine.

Where it does surface is in cash. A large share of business-to-business sales in the UAE is paid late, and the latest survey of local firms attributes the delays less to customers being unable to pay than to the administrative machinery between an invoice arriving and an invoice being approved.

The survey does not break those delays down by cause, and nothing here claims it does. What it establishes is that the slow part is administrative. An invoice that cannot be matched to an order, or that names a customer entity the buyer's system does not recognise, is exactly the kind of invoice that sits in that machinery, and the supplier's own data decides how often that happens.

Duplicate customer records

Duplicates are the most common of the six and the easiest to underestimate. They come from a short list of sources: a new customer created by someone who searched under a slightly different spelling, a subsidiary set up separately from its parent, a trading name and a legal name held as two entities, and records carried over from an older system without being reconciled.

Each duplicate splits the history of one relationship across two records. Payments land against one and invoices against the other. Credit limits are checked against half the exposure. A statement sent to the customer is wrong in a way the customer notices before the supplier does.

Electronic invoicing raises the cost of this particular defect. The buyer's tax identifier and the buyer's electronic address are both mandatory fields, so the record an invoice is drawn from has to carry both, correctly. Two records for one customer are two chances for one of them to be incomplete.

The fix is rarely technical. It is a rule about who may create a customer, what they must search before doing so, and which identifier counts as the key. A tax registration number makes a better key than a name, because two people will spell a name differently and are far less likely to vary a registration number.

Reference numbers that arrive late

Many buyers will not approve an invoice that does not quote their purchase order number. That number is generated inside the buyer's own procurement process, often after the work has been agreed and sometimes after it has been delivered, and it has to travel back to the supplier's billing team before the invoice can be raised.

When it arrives late, the supplier has two options and both are poor. It can hold the invoice, which delays the cash, or issue it without the reference and amend it later, which creates a second piece of work and often a credit note as well.

The handoff that breaks here is not inside the supplier at all. It runs between the buyer's procurement team and the supplier's billing, with an account manager carrying the number by email in between. Fixing it means deciding where in the supplier's own process the reference is requested, and making the invoice depend on it being captured at that point rather than chased afterwards.

The reference format problem is a variant of the same thing. When a customer changes how it numbers its orders, nothing in the system notices. A person notices, adapts, and becomes the only place the new rule is written down.

Price sources that are not the price source

Most businesses have one official price source and several actual ones. The official one is the item file in the invoicing system. The actual ones are the commercial team's spreadsheet, last quarter's quote, the contract schedule, and the discount agreed on a call.

The system price is right only as often as someone copies the real price into it. Between copies, invoices go out at a price that was correct at the last update and is wrong now. The customer disputes it, a credit note follows, and the credit note closes the dispute without changing the process that caused it.

A credit note closes the dispute. It does not close the handoff that caused it.

The electronic invoice makes this visible in a way the old one did not. Item gross price and item net price, before and after any price discount, are separate mandatory fields, so a discount can no longer be folded silently into a single number. The difference between them has to be known at the point of invoicing, which means the discount agreed on a call has to be somewhere the invoice can read it.

How to count what this costs

The cost of these handoffs is almost never measured directly, because it is spread across people who do not record it. It can be counted without new software, and counting it first is what turns the later decision about automation into an informed one rather than a hopeful one.

• Credit notes. Take a recent period and classify every credit note by the handoff that caused it. Most will trace back to one of the six, and the count by cause is the first map.
• Amended invoices. Count the invoices reissued or edited after first issue, and note why. Late references and wrong prices usually lead.
• Duplicate records. Search the customer file for records that share a tax registration number, a phone number or a near-identical name. Whatever the search finds is a floor rather than an estimate.
• Time. Ask the people who make the corrections to keep a simple tally for a few weeks: what they corrected, and roughly how long it took. The total usually surprises them, because the corrections were never a task with a name.
• Cash. Compare how long invoices that needed correcting took to be paid against those that did not. The gap is the working capital cost of the handoffs, in the business's own numbers.

That exercise is a small version of a diagnostic: establishing what actually happens, with evidence, before deciding what to change.

What to fix first

The instinct, once the corrections are visible, is to automate them. That usually produces a faster way of making the same mistakes, because the automation inherits whatever data the handoffs produce.

The better order is to fix the handoffs and then automate what remains. In practice that means deciding where each piece of invoice data is created, who owns it, and what the invoice is allowed to depend on, and then making the systems enforce those decisions.

• Make the tax registration number the key for customer records, and require a search before any new customer is created.
• Capture the buyer's order reference at the point the work is agreed, and make the invoice wait for it there rather than chasing it afterwards.
• Name one price source. Every other place a price lives either reads from it or is retired.
• Record agreed discounts where the invoice can see them, with the reason attached, rather than in a note or a memory.
• Classify every credit note by cause, every month, and treat a recurring cause as a defect to fix rather than a cost to absorb.

Most of that is process rather than software. Some of it, particularly the matching and checking that has been living in one person's head, suits automation well once the rules exist to be automated. The pattern is not peculiar to invoicing. Among European firms that considered adopting AI and decided against it, problems with the data itself were cited more often than cost.

A business that maps its handoffs before the electronic invoicing deadline gets two things from the same work: invoices that pass validation, and data clean enough to automate against afterwards. If it would help to see where yours break, book a call and the conversation will start with the handoffs rather than the software.