# 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. Every European e-invoicing mandate covers invoices only, because mandates are VAT law and a purchase order creates no taxable event. Peppol does define ordering profiles, but nothing requires them. So in mandated markets the invoice is structured XML while the order that started it is still a PDF. 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](/e-invoicing) sets out which country requires a format, a network, both, or neither, and the [ERP support guide](/guides/e-invoicing/does-your-erp-support-peppol) 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](https://docs.peppol.eu/poacc/upgrade-3/profiles/3-order-only/), OpenPeppol - [VAT in the Digital Age (ViDA) digital reporting requirements](https://www.vatcalc.com/eu/eu-2028-digital-reporting-requirements-drr-e-invoice/), vatcalc ## Related reading - [European e-invoicing mandate timeline](/e-invoicing) - [Peppol ordering profiles in detail](/guides/e-invoicing/peppol-order-documents) - [Peppol is not e-invoicing](/guides/e-invoicing/peppol-vs-e-invoicing-mandates) - [EDI Inspector](/edi-inspector), free in-browser EDI file reader