Build an e-invoice status model finance can trust
When a screen says an invoice is accepted, ask who accepted it and for what purpose. A connector accepting a request, a buyer approving a charge and a tax authority validating a document are different events. Collections and support teams need that distinction before they act.
Use this guide to produce a status dictionary for the actual provider and ERP combination you operate. Complete the status mapping worksheet with finance and integration owners. The proposed controls are an operating design, not a universal legal sequence.
Identify the decisions the screen must support
Start with real operator questions. Has the customer received the invoice? Is a commercial dispute open? Does reporting need intervention? Is cash allocated to the debt? Record the evidence required for each answer.
Assign billing ownership of the issued document, integration ownership of response capture, tax ownership of statutory completion and treasury ownership of cash evidence. AP or customer service owns the buyer decision where your business is the receiver. A status should identify the next responsible operator rather than merely color a tile.
Do not ask one field to answer every question. Maintain separate dimensions for document preparation, technical processing, recipient delivery, business processing, authority reporting and financial settlement where they apply. Mark inapplicable dimensions explicitly so an absent optional response does not look like a failed compulsory step.
Read the response before naming the status
Obtain real sample messages and the implemented specification from the provider. Record the message sender, subject document, event time, result, reason and correlation identifier. Ask whether a positive result covers one document or only receipt of a batch.
Peppol's Message Level Response distinguishes transport acknowledgments from validation responses. A validation response describes checks on document content, which is a different assertion from business approval. OpenPeppol, BIS Message Level Response.
The newer Message Level Status specification defines a service-level status exchange within Peppol delivery. Confirm the version and role actually implemented rather than treating every message called a response as the same interface. OpenPeppol, Message Level Status 1.1.0.
Peppol Invoice Response separately describes business processing, including queries, rejection and payment-related information. Use its defined meaning when mapping a response. A payment-related message is not independent evidence of cleared funds in your bank. OpenPeppol, BIS Invoice Response.
These specifications describe available processes. They do not prove your provider or counterparties support every response. Confirm the released artifacts through the OpenPeppol publication index and retain the agreed version in your configuration record.
Preserve events and derive the current view
Store an immutable event record and derive the current status from it. Keep the raw message, source, receipt time, source event time and mapping revision. Preserve external timestamps with their time zone. Use the subject document identifier rather than matching only on amounts.
Handle repeated and delayed events without changing the business result. The same acknowledgment arriving twice should remain two observed deliveries of one event or one deduplicated event with its receipt history. It must not create a second invoice or payment.
Define the allowed transition for each dimension. A delayed transport acknowledgment should not overwrite a later buyer dispute with a misleading overall accepted label. If events contradict one another, open an investigation and show the conflicting evidence. Avoid silently selecting whichever message arrived last.
Work a delivered but disputed invoice
Consider a synthetic invoice for 1,000 net plus fictional 10% tax, giving 1,100 gross. There is one commercial invoice and no authority-reporting step in this example. The buyer supports the agreed business-response process.
At 09:00 the ERP issues the invoice. At 09:01 the provider acknowledges receipt. At 09:03 delivery evidence arrives. At 11:00 the buyer places the invoice under query because the order reference is missing. No cash has arrived.
The correct view is provider processing complete, recipient delivery confirmed, buyer query open and settlement outstanding at 1,100. Billing asks the contract owner to resolve the reference. It does not send another invoice merely because the buyer query appeared.
Suppose a duplicate of the 09:01 acknowledgment arrives at 12:00. The query remains open. A mapping that changes the overall label back to accepted has lost a material business fact even though no accounting amount changed.
The buyer later resolves the query and communicates its acceptance. A payment-related response then arrives, but treasury sees only an unallocated bank receipt of 600. Record the response as evidence from the buyer and investigate the cash. After treasury verifies and allocates the 600, the receivable balance is 500. Do not clear the full 1,100 solely because the buyer's message sounded final.
This example establishes internal expectations. The actual scheme's response codes, meanings and availability need their own mapping.
Define what silence means
For each expected response, record whether it is required, optional or unavailable. Set an internal review threshold based on service arrangements and legal deadlines. An internal support threshold is not a statutory grace period.
If a buyer does not support business responses, show that capability as unavailable. Continue commercial approval or dispute tracking through the agreed channel. An invoice cannot become overdue in the response queue merely because an unsupported optional message never arrives.
For an expected authority response, missing evidence may be a genuine reporting exception. Integration should query the documented status mechanism before retrying. Tax decides any deadline or fallback action. Keep that issue separate from customer delivery if delivery already succeeded.
Give operators a safe next action
Pair each actionable status with an owner and a permitted action. For rejected content, route the reason to the data owner. For an unknown result, investigate the existing attempt. For a commercial query, contact the business approver. For unmatched cash, route to treasury.
Restrict automated actions to the evidence they actually require. A successful transport response might permit archiving the delivery record. It should not release a supplier payment or authorize a tax claim unless the separately approved conditions also pass.
Test the user view with delayed, duplicated, absent and contradictory messages. Check the audit export as well as the screen. A readable screen with no retrievable raw evidence will be difficult to investigate after a provider change.
Approve the dictionary and review it after change
- ☐ Every mapped status names the actor, assertion and subject document.
- ☐ Delivery, business processing, reporting and settlement remain distinguishable.
- ☐ Missing optional responses do not create false failures.
- ☐ Delayed or duplicate events cannot regress a valid later decision.
- ☐ Unknown and conflicting outcomes reach a named operator.
- ☐ Financial actions require their own approval and cash evidence.
- ☐ Samples, mapping versions and raw responses remain retrievable.
The finance operations lead approves the dictionary and integration maintains the mapping. Recheck it when a provider, profile, ERP connector or reporting service changes. Use the outage recovery guide for ambiguous attempts and the reconciliation guide for period completeness.
Sources checked 17 October 2026. No response capability is inferred for an untested ERP or provider.
Worksheet: Invoice status event mapping
Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment.
Show the worksheet
Use with the status-model guide. Complete one mapping per service, profile and implemented version. Attach actual sample messages.
Define the service
- Entity, direction and document types: ____
- ERP, connector, provider and environment: ____
- Implemented specification and mapping version: ____
- Finance approver and integration owner: ____
Map each event
Copy this block for every event type.
- Source actor and original code: ____
- Subject document and correlation key: ____
- Exact assertion the event establishes: ____
- Dimension affected: preparation, validation, delivery, business processing, reporting or settlement: ____
- Required, optional or unavailable: ____
- Source timestamp, receipt timestamp and time-zone treatment: ____
- Normalized status and permitted transition: ____
- Raw evidence location and retention decision: ____
- Responsible operator and next permitted action: ____
- Internal review threshold and separate legal deadline if applicable: ____
Test the event history
- ☐ Duplicate acknowledgments cannot create another business document.
- ☐ A delayed acknowledgment cannot erase a later buyer query.
- ☐ Missing optional responses do not appear as compulsory failures.
- ☐ Contradictory messages open an investigation with preserved evidence.
- ☐ Payment-related responses do not replace cash-allocation evidence.
Synthetic control: a 1,100 invoice with 600 verified and allocated cash leaves 500 outstanding, even if a buyer's response suggests payment is complete.
Observed result, evidence and defect owner: ____
Finance acceptance and date: ____
Integration acceptance and date: ____
Related on this site
- Country pages: key facts with sources
- E-invoicing matrix: country × ERP support
- All guides
Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17.
Related: Glossary – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).
Page last updated: · Markdown version