Invoice customer: what each role knows and where the gaps cause trouble
Sales knows what was promised. Operations knows what was delivered. Billing knows what the system will print, and the customer's payables clerk knows what will be accepted. Trouble sits where these meet: wrong prices, rejected invoices, credit notes nobody can explain and receivables that only look collectable.
Sales and account management
The account manager carries the deal in their head. Special pricing, a free first shipment, a verbal agreement to waive freight. Much of this never reaches the contract file, let alone the price list.
When the invoice goes out at standard price, the customer disputes it. The billing team has no idea why. They raise a credit, the account manager confirms it by email, and the same error repeats next month because the master record was never corrected.
Operations and fulfilment
The warehouse or service team knows what actually left the building. Partial shipments, substitutions and a job that ran over scope are all visible on the floor. They are often invisible in the order.
If billing is triggered by the order and not by confirmed delivery, the invoice describes something that did not happen. The customer's goods receipt will not match. That mismatch is the single most common reason a correct looking invoice sits unpaid.
Master data
Whoever maintains customer and product files knows how the record was built. They know which fields drive tax, which address prints on the invoice and which one is used for delivery.
They rarely know the customer's real requirements. A customer may insist on a purchase order number on every line, or a specific legal entity name, or a portal upload in place of email. These rules live with the account team or the collector who learned them the hard way. Until they are written into the record, every invoice is a gamble.
Billing
Billing staff know the mechanics. They see which orders failed to generate, which jobs ran late and which invoices bounced back from a dead email address.
What they lack is context. A blocked invoice looks like a system fault. Often it is a commercial question that only sales can answer. Billing tends to work around these with manual edits, which fixes the document and hides the cause.
Receivables accounting
The receivables accountant knows what posted, what was credited and what was adjusted. They see the ledger as it is, not as it was meant to be.
They often do not know why an adjustment was made. A credit memo with a vague reason code tells them nothing about whether it was a pricing error, a goodwill gesture or a write off in disguise. Revenue reporting suffers, and the auditors ask questions nobody can answer quickly.
The customer's payables team
This is the role most process designs forget. The customer's clerk matches invoice to order to receipt, routes anything unusual for approval, and holds whatever fails. They know exactly why an invoice was rejected.
They seldom say so clearly. A rejection may come back as a generic portal message, or not at all. The supplier learns of it only when a collector calls about an overdue balance and is told the invoice was never accepted.
The inquiry desk
Whoever handles billing inquiries sees patterns before anyone else. The same customer disputing freight. The same product carrying the wrong tax code. A new contract whose terms never made it into the system.
That knowledge usually stops at the desk. Each inquiry is resolved and closed. There is no route back to master data or sales, so the fix is applied to one invoice and the fault stays in place.
Where the gaps compound
The worst failures cross more than one boundary. A promised discount missing from the price file produces a wrong invoice. The customer holds it. The collector chases it. The inquiry desk issues a credit. Receivables posts an adjustment with no useful reason. Each person acted correctly with what they knew, and the business still billed wrongly, collected late and cannot explain its revenue.
Changing any single step without closing these gaps tends to move the problem downstream.
Questions to ask the people who run it
What people actually do often differs from the documented procedure. These questions tend to surface the difference.
- When an invoice is blocked, who decides what to do with it, and how do they find out the reason?
- Which customers have rules that are not in the system, and where are those rules written down, if anywhere?
- How does billing learn that a shipment was partial or a job changed scope?
- When a customer rejects an invoice, how is that reported back, and who hears first?
- What happens to an inquiry after it is closed? Does anyone look for repeats?
- Who can change a price or a payment term in the master file, and who actually asks them to?
- How are credit memo reasons chosen, and would someone outside the team understand them?
- Which manual edits happen every cycle that nobody has asked to stop?
- When did a collector last pass a customer requirement back to the team that creates the invoice?
Sources
APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.