Billing controls: accurate documents and traceable corrections

A billing control should answer a specific question with observable evidence. “The invoice looks right” cannot detect a duplicated source order, cash counted twice or an invoice sent from the wrong company. Start with the risks in your own service flow, then place a check where it can stop or detect that error.

This is a control design for your operating team. Use your existing management process for review and separation of duties; this article does not imply that the application provides a configurable approval engine.

Establish the control register

For each control, record the risk, population, owner, frequency, evidence and action on failure. Identify the source of truth for customer identity, commercial amounts, payment confirmation and accounting posting. When two systems can alter the same financial field, designate the authority and the reconciliation point before automation.

A small team may combine roles. Compensate with a later independent sample and a visible exception register rather than claiming independence that does not exist.

Before issuing an invoice

Check the active company, supplier name and enterprise identity first. Then verify customer name, identifier, complete address, required purchase-order reference, currency, issue and due dates. An API address requires street, city, postal code and country; a partial address is refused.

Compare the commercial source with the lines, quantities, prices, discounts and tax categories. Do not derive an invoice total solely from the PDF or a paid badge. Let a controller confirm unusual tax treatment and use capabilities returned by GET /api/v1/me for integration support decisions. Unsupported schemes require resolution before numbering or transmission.

For API creation, omit number when the company sequence should assign it. Keep a stable external_id for the source transaction and an Idempotency-Key for request retries. A lost response is a recovery problem, not a reason to create the same transaction again with a new identity.

Keep three states separate

Commercial lifecycle, Peppol delivery and settlement answer different questions. A delivery confirmation does not establish buyer approval or cash receipt. A payment movement records confirmed money; it does not send a payment instruction to a bank. A refund movement records a refund completed outside OrdoGrid.

Read settlement fields together:

• document_total is the original invoice gross total.
• payments includes active prepayments; never add prepayments again.
• credits is linked legal credit-note value, not cash.
• outstanding and refund_due describe the remaining debt or refundable amount.

Reconcile those values against source evidence, with currencies kept separate. Do not net an unrelated customer's debt against a refund to make a control pass.

Correct the cause and preserve the chain

A wrong commercial amount on a frozen financial document needs the appropriate credit and replacement process. A wrong cash entry needs a movement correction. Full movement reversals link to the original movement; partial corrections use a full reversal and a replacement confirmed movement. A payment with an active completed refund allocation cannot be reversed until the mistaken refund is appropriately reversed.

Keep the original invoice, linked credit note, cash evidence, reversal and replacement references in the case. The OpenPeppol billing specification defines invoice and credit-note structures; your tax and accounting owner decides the correct commercial correction for the facts.

Worked control example

An invoice totals €121. A €40 deposit and later €81 payment settle it. The settlement reports payments €121, including the deposit. A spreadsheet adding payments plus prepayments would incorrectly report €161 and flag a false overpayment.

After a €60.50 credit, refund due becomes €60.50. Treasury confirms an actual €60.50 refund and operations records it using its own stable movement identity. The control passes only when refund due is zero, the external refund evidence exists and the credit remains linked to the original. Marking the invoice “paid” is insufficient evidence.

Run detection and handle exceptions

Review source/document counts, duplicate identities, unresolved delivery, negative or unexpected settlement changes and missing archive retrievals at a frequency suited to volume. Sample unusual tax, manually entered payments and changed supplier details more heavily. Store the population and selection method so a reviewer can reproduce the result.

Quarantine unexplained differences from further automatic processing, assign a person and retain the original error. A repeated EXTERNAL_ID_REUSED is a mapping or identity defect; a DOCUMENT_FINANCIAL_CONTENTS_LOCKED refusal is a signal to use the correction path. Neither should be bypassed with a fresh ID.

Hand unresolved period-end cases to the controller with amount, currency, cause, impact, next action and due date. Use month-end reconciliation for the close and integration reliability for automated recovery.