How customer invoicing is set up in finance and ERP systems

In most ERP systems, customer invoicing sits inside the order-to-cash cycle. Master data defines who gets billed and at what price. Billing runs turn shipments, contracts or time records into invoices. Those invoices are sent out, posted to receivables and the general ledger, and corrected through credit memos when disputes arise.

Master data comes first

Almost every invoicing problem traces back to the customer or product record. The customer master holds the legal name, bill-to and ship-to addresses, tax registration, payment terms and the preferred delivery channel for invoices. Larger organisations separate the sold-to party from the payer, so one parent company can settle bills for many sites.

Product and pricing records sit alongside it. These include price lists, discount agreements, tax codes and revenue account mappings. When a price changes in a contract but not in the system, the invoice is wrong before anyone touches it.

Ownership of these records is often split. Sales may create customers. Finance may approve credit limits. A master data team may control changes. Knowing who can edit what matters more than the screen layout.

Where billing data originates

Invoices rarely start in finance. The trigger is usually an upstream event: goods leaving a warehouse, a service milestone being signed off, a subscription period starting, or hours being approved in a project tool.

ERP systems handle this with a billing document or billing due list. A scheduled job collects everything that is ready to bill, applies pricing and tax, and creates draft invoices. Some setups bill each order on its own. Others combine many deliveries into a single periodic invoice per customer.

Contract and subscription billing often runs in a separate module or an external platform. In that case, invoice data flows into the ERP through an interface. Each handoff is a point where records can be dropped or duplicated.

Getting invoices to customers

Output settings decide how each invoice leaves the building. Common channels include printed paper, PDF by email, uploads to customer procurement portals, and structured electronic formats. In several countries, e-invoicing rules require submission to a government platform before the invoice is legally valid.

The customer record normally drives the channel choice. Portal customers tend to cause the most friction, because each portal has its own fields, purchase order rules and rejection messages. Rejections often land in someone's inbox and never reach the ERP.

How the posting works

When an invoice is released, the system posts a debit to the customer's receivable account and credits to revenue and tax liability. A reconciliation account in the general ledger mirrors the customer subledger, so the two should always agree.

Revenue may not be recognised at the moment of billing. Where accounting rules require deferral, the posting goes to a contract liability and is released over time by a separate process. Billing and revenue recognition are configured independently, and they can drift apart if nobody checks.

Payment terms set at posting determine the due date that drives dunning, cash forecasting and ageing reports downstream.

Credits, adjustments and inquiries

Customers question invoices for many reasons: wrong quantity, missing purchase order reference, disputed price, damaged goods. The standard fix is a credit memo linked to the original invoice, sometimes followed by a corrected rebill. Systems usually route credit requests for approval above a threshold set by policy.

Good setups capture a reason code on every credit. Without it, nobody can see whether errors come from pricing, logistics or sales promises. Inquiries themselves are often logged in a CRM or a shared mailbox. The ERP only sees the eventual adjustment, so the full history lives somewhere else.

Smaller corrections, such as write-offs of trivial balances or tax rounding, often go through manual journal entries or adjustment documents. These deserve the same scrutiny as credit memos.

Controls usually built around it

Typical controls include segregation between those who maintain pricing and those who issue credits, sequential invoice numbering, and a reconciliation of shipped-but-unbilled items at period end. Many teams also review a sample of invoices before release for key accounts. Audit trails on master data changes are expected by most external auditors.

Questions to ask the people who run it

What the configuration says and what the team does day to day are often different. These questions tend to surface the gap:

• Which invoices get edited or held by hand before they go out, and why?
• Where do customer complaints arrive first, and how do they reach whoever can issue a credit?
• Are there customers billed outside the system entirely, through spreadsheets or a separate tool?
• Who changes prices in the system, and how do they hear about new contract terms?
• What happens when a portal rejects an invoice? Who sees the message?
• Which month-end steps exist only because billing runs late or incomplete?
• Are credit memos ever issued without a link to the original invoice?
• What workarounds would break if the billing job ran differently tomorrow?

The answers usually point to the real control points, and to the manual effort a redesign will need to absorb or remove.

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.