Peppol BIS Billing links invoice verification to source records
Peppol BIS Billing supports invoice verification against order, contract, receipt, and delivery references. Buyers still need governed records for approval, exceptions, tax, accounting, and payment.
Editorial figure by Procurement Technology Current. Source context: OpenPeppol.
An invoice is a connected commercial record
Peppol BIS Billing defines an interoperable invoice and credit-note process rather than an isolated payment request. Its stated business functions include verification, accounting, VAT reporting, auditing, and payment. For verification, the specification identifies records such as a purchase order, contract, tender, buyer reference, receipt advice, and delivery note that can provide context for the invoice.
A procurement system should preserve those relationships as typed, versioned references. The invoice identifier, seller and buyer, order or contract reference, delivery evidence, line, amount, tax information, currency, correction, and status need to remain distinguishable. Copying all of that into one approval note makes it difficult to determine which record supplied a value, whether the source later changed, or why an exception was accepted.
Document conformance is not business approval
A message can conform to the Peppol usage specification and still require buyer-side review. The specification provides a shared structure and business terms, but an organization still decides whether an invoice matches an authorized commitment, received quantity, contract price, tax treatment, delegated authority, duplicate policy, accounting period, and payment control.
Technology evaluations should therefore separate syntax and business-rule validation from approval. The first asks whether the document is structurally valid for the exchange. The second uses authoritative procurement, receiving, finance, tax, supplier, and policy records to decide what happens next. A successful network delivery or validation result is evidence about transport and document conformance, not proof that the liability is correct or payable.
Exceptions and corrections require lineage
The specification covers both invoices and credit notes, making correction history central to an auditable process. Systems should retain the original document, subsequent credit or corrected document, relationship between them, validation results, discrepancy, reviewer, approval or rejection, and downstream posting or payment state. An updated balance alone cannot explain which commercial document changed it.
The source also defines boundaries. Inventory management, delivery processes, customs clearance, marketing, and reporting are outside its scope. A buyer should not assume that support for Peppol billing supplies those adjacent capabilities or reconciles their records. Product claims should identify which edition and syntax are supported, which business rules are enforced, what source systems are connected, and where accountable human decisions remain.
Test one invoice across the control chain
A representative demonstration can begin with a valid invoice containing an order reference, several lines, partial receipt evidence, tax information, and an agreed contract price. Introduce a supplier-identity mismatch, a missing order reference, an overbilled line, a duplicate document number, and a later credit note. Ask the platform to show which checks came from the Peppol specification, which came from buyer policy or source data, and who resolved each exception.
Then reconcile the invoice through posting and payment without overwriting the earlier states. The system should preserve the received document, source references, validation version, decision history, correction relationship, export or integration events, and final disposition. Peppol BIS Billing supplies a durable interoperability baseline; legal sufficiency, tax treatment, accounting judgment, procurement authorization, and product fitness remain buyer-specific determinations.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Procurement Technology Current will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.