Month-end reconciliation: documents, settlement and delivery
A close procedure for reconciling commercial invoices, confirmed cash, credits, refunds, Peppol evidence and legacy exceptions by entity.
- Updated
- Content owner
- Financial control
- For
- Financial controllers · Accounting teams · Integration owners
At a glance
Reconcile the same population and cutoff across source documents, settlement and cash, while tracking delivery and archive exceptions separately.
Before you begin
- An agreed close cutoff and entity/currency scope
- Source document and confirmed cash registers
- Read access to document settlement, movement histories and transmission evidence
What you will achieve
- Explained document and cash differences
- A reproducible close evidence pack
- An owned register of unresolved legacy and delivery exceptions
On this page
Month-end reconciliation should explain how commercial activity became debt, how cash changed that debt and which documents were exchanged. These are related populations, but one status cannot reconcile all three. A delivered invoice may be unpaid; a settled invoice may still have a delivery exception.
Use this procedure for an entity close or a shared-service portfolio. It describes a manual or integration-supported operating process, not a promised one-click accounting export.
Fix the population and cutoff
Write down the legal entity, currency, document kinds, period and timezone. Distinguish issue date, payment occurrence time and recording time. Late-recorded cash may belong to an earlier business period; record your accounting treatment instead of quietly moving the cutoff.
Capture a source extract and a product extract with retrieval timestamps. API list calls use limit and offset; the maximum limit is 100. Read every page and detect population changes if posting continues during extraction. Either agree a processing pause or reconcile the movements arriving between the initial and final snapshots.
| Workstream | Owner | Reconciliation evidence |
|---|---|---|
| Invoice and credit population | Accounting | Source counts, identities and gross totals |
| Cash and refunds | Treasury | External confirmations and movement histories |
| Settlement differences | Controller | Per-invoice bridge and reasons |
| Delivery and archive | Operations | Exception list and retrieval evidence |
| Extraction completeness | Integration owner | Filters, page counts and timestamps |
Keep currencies separate. The product does not provide currency conversion or a customer wallet to net balances across invoices.
Reconcile documents before balances
Match invoices and credit notes by stable source external_id, integration namespace and document kind, then by assigned product ID and number. Counts alone will miss one duplicated order and one omitted order of equal value.
Explain missing, extra and changed records individually. A deleted lifecycle is still a document record; do not assume it disappeared from accounting evidence. Check credit notes against their original invoice ID or external invoice-number reference and confirm they have not been counted twice.
Compare tax categories and net/gross amounts where the accounting mapping depends on them. Escalate unsupported tax treatment rather than forcing totals into a generic category to close the period.
Bridge each invoice's settlement
Use authoritative settlement values rather than an inferred paid label:
outstanding = max(0, document_total - credits - payments + refunds)
refund_due = max(0, payments - refunds - (document_total - credits))
Payments already include prepayments, net of payment reversals. Refunds are completed cash returns recorded in the product, net of refund reversals. Credits change commercial debt but do not prove that cash moved.
For each invoice, retain original gross total, linked credits, confirmed payments, refunds and remaining balance. Retrieve movement history when the summary differs from source cash evidence. Use stable movement identities to distinguish a replay from a second actual tender.
Example: deposits and credit after payment
Invoice A totals €121, with a €40 deposit and €21 later payment. Settlement payments are €61 and outstanding is €60. Counting the deposit again produces an incorrect €20 balance.
Invoice B totals €121 and is fully paid. A €60.50 credit produces refund due €60.50. If treasury completed the refund on 30 September but operations recorded it on 2 October, both timestamps belong in the close case. The controller decides the period treatment. The operational register must still reconcile the external refund and product movement.
Deal with legacy and unresolved cases
Historical paid records may carry legacy_reconciliation_required. That flag does not invent a cash transaction. Put each case in a separate register with invoice amount, available bank/till evidence, missing evidence, proposed correction and accountable owner. Never manufacture a payment to suppress the flag.
A movement mismatch needs cash-owner confirmation. A financial difference after transmission may require a credit note or movement correction because the issued financial contents are frozen. A lookup conflict or reused external identity goes to the integration owner with the original source payload.
Track uncertain Peppol sends, rejected deliveries and missing archive files independently from settlement differences. A payment should not hide an unresolved transmission. Follow incident response for material or systemic exceptions.
Assemble the close evidence and handoff
The close pack contains the fixed scope, source extracts, retrieval timestamps, mapping version, reconciliation totals by currency, per-record differences and the signed decision in your accounting process. Include an archive sample and the list of delivery exceptions so the evidence remains usable beyond a spreadsheet total.
Acceptance means all financial differences are explained, every residual case has an owner and date, and a second person can reproduce the population and balance bridge. Do not label an unexplained difference “timing” without its actual event and expected resolution.
Carry open cases into the next period and verify their resolution before removing them. Use billing controls to prevent recurring differences and integration reliability to fix extraction or identity defects.