Peppol Solved the Invoice. Nobody Solved the Order.
Europe mandated structured e-invoicing and it worked. The purchase order that starts the same transaction is still a PDF in an inbox, and no regulation is coming for it. Here is the structural reason why.
In Belgium, since January 2026, every business-to-business invoice is a structured document travelling over a managed network with a public participant directory. It validates against a published ruleset. It arrives in a form a machine can book without a human reading it.
The purchase order that started that same transaction is very often a PDF attached to an email.
That gap is not a gap in adoption. It is the designed outcome of how these mandates came about, and understanding why explains something useful about which problems regulation can solve and which it structurally cannot.
The mandates worked, and they worked fast
It is worth being clear that European e-invoicing is a policy success. Belgium, Poland, Italy, and Greece already require structured B2B invoices. Germany has required every business to be able to receive one since January 2025, with issuing phased in through 2027 and 2028. France requires universal receiving capability from 1 September 2026. ViDA extends it across intra-EU B2B supplies from July 2030.
Roughly half of Norway's estimated 140 million annual B2B and B2G invoices already move electronically over Peppol. Adoption at that scale, in under a decade, is not a small thing.
Every one of those rules covers invoices
Not one covers purchase orders. Not ViDA, not Germany's Growth Opportunities Act, not France's approved-platform regime, not Poland's KSeF, not Italy's SdI.
The reason is that these are all VAT laws. A tax authority regulates what it can audit for tax, and an invoice creates a liability. It is the document that says money is owed and VAT is due. That gives the state both an interest and a legal basis.
A purchase order creates nothing taxable. It is a statement of intent. No VAT event, no audit interest, no standing to dictate its format.
So this is not a case of ordering being deferred to a later phase. It is out of scope by construction, and it will stay out of scope, because the mechanism that produced invoice adoption has nothing to grip.
Peppol built the ordering side anyway
The specifications exist and have for years. BIS Order Only 3.3 for a simple order. BIS Ordering 3.3 when you want a formal Order Response so the seller can accept, reject, or counter line by line. Advanced Ordering 3.0 for change and cancellation. Despatch Advice 3.1 for the shipment. All UBL, all over the same network, all using the same participant identifiers as the invoice.
Adoption is thin. Where it exists, it got there through purchasing power rather than law: Norway and Denmark's public sectors, Finland moving public procurement to e-orders in 2024, the UK NHS requiring Peppol messaging from suppliers through its eProcurement Strategy.
That is the Walmart-forced-EDI pattern, not the France-2026 pattern. It spreads contract by contract, sector by sector, and it never produces a dated national deadline.
The asymmetry that keeps it that way
Here is the part that actually explains the adoption curve, and it is not about technology at all.
Invoicing is one-sided. You can adopt it alone. You start issuing structured invoices and your counterparty is legally obliged to be able to receive them. Their readiness is their own legal problem, not a precondition for you.
Ordering is two-sided. You cannot receive a Peppol order unless your customer decides to send one. Every single connection requires both parties to have moved, and no law makes either of them move first.
One of these can be solved by a mandate. The other is a coordination problem, and coordination problems without a forcing function stay unsolved more or less indefinitely.
Which is why the invoice leg standardised in under a decade while the order leg did not move at all.
What that means if you sell things
If you are a distributor or manufacturer selling into Europe, the practical consequence is that your two document flows are diverging.
Outbound invoices are becoming structured, validated, and machine-readable, because the law requires it and your ERP vendor is shipping it. That problem is being solved for you.
Inbound orders are not. They still arrive as PDFs, as text in the body of an email, as spreadsheet attachments, as portal exports someone downloads manually, as EDI from your larger accounts, and occasionally as a voicemail. And unlike the invoice side, there is no standards body, no deadline, and no ERP vendor roadmap item coming to fix it.
That asymmetry is worth sitting with. The half of the transaction that got regulated is the half that was already the most structured. The messy half stayed messy.
Why nobody is coming for the messy half
There is a reason that is worth naming plainly.
Systems of record absorb defined work against a published standard. EN 16931 has a schema. Give an ERP vendor a specification and twenty-four months and they will ship a module, which is exactly what happened: Odoo shipped a built-in Peppol access point, NetSuite shipped an Electronic Invoicing SuiteApp, Business Central shipped native Peppol format support.
Undefined work does not get absorbed that way. There is no standard for "a PDF that is laid out differently every time", so there is nothing to implement. It needs document interpretation, an evaluation harness to know whether the interpretation was right, and a review queue for the cases where it was not. That is a different kind of engineering than implementing a schema, and it is not on anyone's compliance roadmap.
The absence of a mandate is precisely why nobody is coming.
The practical read
Solve invoice compliance with whatever fits the countries you actually trade in, and check what your ERP already ships before you buy anything, because the answer is often more than teams expect. Our mandate timeline sets out which country requires a format, a network, both, or neither, and the ERP support guide covers who ships what.
Then treat inbound orders as the separate problem they are, because no regulation is going to merge them for you.
That second half is what OrderSync does: it reads orders in whatever shape they arrive, PDF, email, spreadsheet, portal export, EDI, or voicemail, and posts them into your ERP as structured orders. It runs alongside your invoice compliance stack rather than replacing it, because they are genuinely different problems.
Sources
- Peppol BIS Order Only 3.3, OpenPeppol
- VAT in the Digital Age (ViDA) digital reporting requirements, vatcalc
Related reading
- European e-invoicing mandate timeline
- Peppol ordering profiles in detail
- Peppol is not e-invoicing
- EDI Inspector, free in-browser EDI file reader
How to Answer "Are You EDI Capable?"
A buyer asked, and you need to answer this week. The four things they are checking, what you can say yes to today, and a realistic date for the rest.
- What a buyer is really asking when they ask this
- The minimum set-up that makes the answer yes
- What you can answer today versus what needs building
- Rough timelines, so you can give a date rather than a maybe
One email with the download. Unsubscribe any time.
Stop manually entering orders
OrderSync turns EDI, email, PDF, and fax orders into structured data automatically. See how it works for your business.
Accounts Payable Automation: How It Works
FSMA 204 KDEs From Suppliers Who Do Not Send EDI
Related Articles
Blanket Purchase Order: How Releases Work
A blanket purchase order commits to a total quantity over a period, drawn down by releases. See how call-offs work, with a worked drawdown example.
ProcurementGoods Receipt: The Missing Leg of 3-Way Match
How the goods receipt process records physical receipt against a PO, feeds the GR/IR account, and completes the three-way match. EDI 861 explained.
ProcurementProcure-to-Pay Process: The 7 Steps Explained
The procure-to-pay process runs from purchase requisition to payment. See all 7 steps, the EDI documents behind each, and where three-way match fits.
ProcurementProcure-to-Pay Software: What to Look For
An honest buyer's guide to procure-to-pay software: core modules, suite vs point vs ERP-native, build vs buy, and what mid-market suppliers really need.
ProcurementPurchase Order Approval Workflows That Scale
How to design a PO approval process with amount thresholds, budget checks, multi-level sign-off, and segregation of duties that holds up as you grow.
ProcurementWhat Is a Purchase Requisition? (vs Purchase Order)
A purchase requisition is an internal request to buy, approved before it becomes a PO. See what it contains, the approval workflow, and requisition vs PO vs RFQ.
ProcurementMore from the Blog
FSMA 204 Deadline: July 20, 2028, Not January 2026
The FSMA 204 compliance date moved to July 20, 2028. Here is the full timeline, the statutory basis for the delay, and what did not change when the date did.
IndustryFSMA 204 Shipping CTE on an EDI 856: Segment by Segment
Where the Traceability Lot Code and FSMA 204 shipping KDEs actually sit in an EDI 856 ASN. The hierarchical loop, the LIN and N9 segments, and what breaks in practice.
EDICan an Invoice Carry FSMA 204 Traceability Data?
Why the EDI 810 invoice cannot carry lot-level traceability the way an 856 can, what a PDF invoice is genuinely useful for under FSMA 204, and where the reference document KDE fits.
IndustryFSMA 204 KDEs From Suppliers Who Do Not Send EDI
Half your supplier base will still be emailing PDFs in 2028. How to capture FSMA 204 Key Data Elements from invoices, packing lists, and faxes without hand-keying every one.
Industry