A Belgian business receiving Peppol invoices should connect them to a controlled approval process, not automatically treat every received document as an authorised purchase. The useful software work starts where a structured invoice meets an uncertain supplier match, missing purchase order, partial delivery or absent approver. Those exceptions determine whether finance can use the new data confidently.
Belgium’s official e-invoicing portal explains the structured electronic invoicing requirement that began on 1 January 2026 for covered transactions between Belgian VAT-liable businesses. Confirm your particular scope and exceptions with the official guidance. This article addresses the operational integration after receipt, rather than deciding a company’s tax obligations.
Follow one disputed purchase into the ledger
Consider a fictional Belgian distributor receiving an invoice for two deliveries against one purchase order. The first delivery is recorded in the warehouse system; the second has arrived physically but has not been confirmed. The invoice reaches finance through a Peppol-connected application, while approval questions move through email.
An integration that immediately posts the full invoice may bypass the existing control. A process that sends the entire document to a generic inbox may preserve the same manual work in a new format. The better brief identifies the evidence required before posting and the person who can resolve each missing fact.
Map receipt, matching, review, approval, posting and subsequent correction as separate steps. Write down which system owns each decision. A finance employee should be able to explain why an invoice is waiting without opening several unrelated applications.
Reuse the network connection you already have
The official software guidance describes software connected to the Peppol network for sending, receiving and processing structured invoices. Before commissioning anything custom, establish what the existing accounting package and selected provider already offer.
Ask for a demonstration using your approval rules, not only a successful invoice exchange. Available configuration may cover supplier matching, document storage or ordinary approvals. Custom software should address a demonstrated gap, such as a warehouse receipt held in a separate system or a purchasing rule specific to your operation.
Keep the network provider and workflow developer’s responsibilities distinct. The integration contract should identify who handles access-point service issues, who corrects internal mappings and who supports an invoice stuck between applications.
Treat supplier matching as a controlled decision
Names are useful for people, but similar names should not be the sole basis for choosing a supplier account. Define the approved identifiers and the circumstances in which a human creates or changes the association. Preserve the received values so a reviewer can compare them with the internal record.
Do not let a newly received bank detail silently overwrite a trusted payment record. Route the change through the organisation’s established verification process. The invoice workflow can highlight a discrepancy and collect a decision; it should not invent an authority that purchasing or finance has never approved.
For multi-entity businesses, test the receiving legal entity as well as the supplier. A valid document delivered to a connected application still needs the correct internal accounting destination.
Build an exception queue with real owners
A practical first version can group work by the reason it cannot progress:
- ▸Supplier identity needs review by the finance master-data owner.
- ▸Purchase reference is absent or does not match an authorised order.
- ▸Quantity or price differs from the agreed purchasing record.
- ▸Goods receipt is incomplete and needs confirmation from operations.
- ▸A possible duplicate needs comparison with an existing invoice.
- ▸Approval is waiting on a person who is unavailable.
Each item should show the relevant evidence, assigned owner, age and permitted next actions. Avoid one broad “error” category that forces finance to diagnose technical and commercial problems together.
Keep the approval record useful after the decision
Record the decision, acting person, time and explanation, with a reference to the invoice version reviewed. If a document is corrected or replaced, make the relationship visible. A previous approval should not automatically apply to changed financial content.
Language also belongs in the workflow design. A Belgian team may operate in Dutch, French or another working language while supplier descriptions vary. Translate interface guidance where needed, but retain source descriptions and identifiers. Agree who checks any translated explanation before it influences an accounting decision.
Give authorised reviewers a readable representation of the structured information. They should not need to inspect raw technical messages to understand a price discrepancy or missing purchase reference.
Acceptance should include a month-end rehearsal
Use synthetic examples to test partial deliveries, credit notes, repeated incoming documents, reassigned approvals and failed ERP posting. Include an invoice approved just before a connection outage. On recovery, the system should establish whether posting already happened before attempting it again.
Ask finance to reconcile the received, pending, rejected and posted populations for the test period. Investigate every unexplained difference. A dashboard count is useful only when its records can be traced back to the source and forward to the ledger.
The release package should contain mapping decisions, role permissions, exception routes and instructions for resolving an uncertain posting. A support owner should be able to follow those instructions without consulting the original developer.
Commission the missing workflow
TuniCyberLabs can help connect a Peppol-enabled provider to purchasing, warehouse and accounting processes through custom software development. Send an invoice-workflow brief with your existing applications and the exceptions that consume finance time. Use the software discovery deliverables guide to define the process map and acceptance evidence before estimating the build.