Exchanging a collective invoice via Peppol: what is and isn’t possible?

Businesses that periodically bundle multiple deliveries or assignments onto a single invoice face a practical question when switching to e-invoicing: can a collective invoice via Peppol still be sent? The answer is nuanced, but requires precision. What the standard allows, what it does not, and what your software and your customer determine — these are regularly conflated in practice.

This article explains step by step how the European invoice standard EN 16931 and Peppol BIS Billing 3.0 handle order references, what does work as a periodic invoicing practice, and which common misconception you can avoid.

What is a collective invoice?

The term ‘collective invoice’ or ‘monthly invoice’ has no formal definition in the European invoice standard. In practice, businesses mean different things by it:

• An invoice at the end of a month covering all deliveries or services in that period, based on a single ongoing agreement or framework contract.
• An invoice consolidating multiple delivery notes, partial deliveries, or call-off orders — all originating from a single purchase order or contract.
• An invoice that merges several separate, independent purchase orders from the same customer into one document.

That third variant — bundling multiple independent purchase orders — is intuitively what most people think of as a ‘collective invoice’, but is precisely the variant that does not fit within the structure of EN 16931 and Peppol BIS Billing 3.0. This distinction is crucial for the rest of this article.

What does Peppol BIS Billing 3.0 prescribe?

Peppol as a network imposes no requirements on the content of an invoice. The content rules come from the European standard EN 16931 and from Peppol BIS Billing 3.0. The latter is a Business Interoperability Specification (BIS) from OpenPeppol: a full implementation specification built around EN 16931. Every valid BIS 3.0 invoice is automatically EN 16931-compliant. At the same time, BIS 3.0 contains additional Peppol-specific validation rules and country-specific rules — going beyond what EN 16931 itself prescribes. BIS 3.0 is therefore more than a mere restriction of EN 16931: it is a specification in its own right that uses EN 16931 as a foundation and builds upon it.

Within that standard, two reference fields at invoice and line level are relevant to this question.

BT-10 and BT-13: two different fields, one common misconception

The standard defines two fields at invoice level that are frequently confused:

An invoice contains at most one BT-13 (Purchase Order Reference) and at most one BT-10 (Buyer Reference). They are separate fields with different purposes. The standard provides no mechanism to include multiple BT-13 values or to reference multiple independent purchase orders.

Peppol validation rule PEPPOL-EN16931-R003 also requires that an invoice contains either a Buyer Reference (BT-10) or a Purchase Order Reference (BT-13) — but this is a minimum requirement, not an invitation to include multiple instances.

BT-132: order line reference — within the same purchase order

At the level of an individual invoice line, the standard provides field BT-132 (cac:InvoiceLine/cac:OrderLineReference/cbc:LineID). The official definition reads:

“An identifier for a referenced line within a purchase order, issued by the Buyer.” — OpenPeppol, Peppol BIS Billing 3.0 syntax documentation

“An identifier for a referenced line within a purchase order, issued by the Buyer.” — OpenPeppol, Peppol BIS Billing 3.0 syntax documentation

BT-132 references a line number within the purchase order specified at invoice level in BT-13. If BT-13 references purchase order PO-2024-001, then BT-132 values on the invoice lines indicate line numbers 1, 2, 3 and so on — all lines of that same purchase order.

BT-132 is not a mechanism to switch between invoice lines referencing different, independent purchase orders. The standard does not provide for this.

BT-132 is not a mechanism to switch between invoice lines referencing different, independent purchase orders. The standard does not provide for this.

Common misconception: multiple orders on one Peppol invoice

A common misconception is that a collective invoice can be constructed by referencing a different purchase order per invoice line, as long as an ‘overarching’ reference (such as a contract number) is provided at invoice level. That reasoning is incorrect, and it is important to clarify this.

There are two separate questions:

• Does the standard support multiple BT-13 values? No — cardinality is 0..1.
• Can BT-132 reference lines from a different purchase order than BT-13? No — BT-132 is by definition a line number within the order of BT-13.

What the standard does allow is the consolidation of deliveries or services that all trace back to a single order or contract. Below are correct and incorrect examples.

Example: correct

Situation: Supplier X has a framework agreement with customer Y (contract number C-2024-05). In January, three deliveries are made under this contract. 

Invoice level: BT-13 = C-2024-05 (contract number as order/contract reference)

Line 1: delivery 5 January — description service A — (BT-132 optional: line 1 of contract)
Line 2: delivery 14 January — description service B — (BT-132 optional: line 2 of contract)
Line 3: delivery 22 January — description service C 

This is one billable entity based on one contract reference. Technically valid and substantively consistent.

Example: incorrect

Situation: Customer Y has placed three separate purchase orders in January: PO-001, PO-002, PO-003. 

Invoice level: BT-13 = ‘see lines’ or a self-invented overarching number

Line 1: reference to PO-001
Line 2: reference to PO-002
Line 3: reference to PO-003 

This does not fit within the structure of EN 16931 / Peppol BIS Billing 3.0. The standard contains no field for ‘alternative PO reference per line’. BT-132 provides line numbers within one order, not alternative order numbers.

 

Practical approaches that do work

If your current practice is based on periodic invoicing, there are generally workable alternatives that are technically valid within the standard — provided the process arrangements with your customer align with them.

Periodic invoicing based on a contract or framework agreement

When all deliveries or services to be invoiced fall under a single agreement (contract number, framework order, service contract), that contract number can be used as the BT-13 reference. Individual deliveries or services are described at line level, optionally with a delivery period (BG-26 within the invoice line). This is the most common and robust approach for periodic invoicing via Peppol.

One purchase order with multiple call-off lines or partial deliveries

If your customer creates a single purchase order for an entire quarter or year, and you deliver against it multiple times, that purchase order can be included as BT-13. BT-132 on the invoice lines indicates which line numbers or deliveries are being invoiced. This works well in combination with automated 3-way matching.

Including a delivery period at line level

Peppol BIS Billing 3.0 offers the option at invoice line level (BG-26) to include a delivery period. This allows you to specify per line which period or specific delivery the line relates to, even without a separate purchase order reference. This is particularly useful for hour- or day-rate services.

Multiple individual invoices as an alternative

If your customer expects a separate invoice per purchase order — standard practice in larger procurement departments — the pragmatic and correct solution is to issue separate invoices per order. Many AP automation systems are explicitly designed for this and process one-to-one matching more efficiently than consolidated invoices.

Checklist for sender and receiver

When invoicing periodically via Peppol (sender)

1. Check whether your deliveries or services all fall under a single contract reference or purchase order — that is your BT-13.
2. Use BT-132 at line level exclusively for line numbers of that one purchase order, not as alternative order numbers.
3. Use BT-10 (Buyer Reference) for internal routing codes from your customer (cost centre, department) — not as a substitute for BT-13.
4. Ask your customer in advance which reference they expect in BT-13 for periodic invoicing: order number, contract number, or project reference.
5. Ask your customer whether their AP system can automatically match multiple invoice lines against the same BT-13.
6. Check whether your software correctly supports and exports BT-132 and invoice line periods (BG-26).

When receiving periodic invoices (receiver / procurement)

• Agree with your suppliers which BT-13 reference you expect — and whether that is your order number, contract number, or another reference.
• Check whether your AP system automatically processes multiple invoice lines against the same purchase order (3-way match).
• Be explicit if your system requires a separate invoice per purchase order — inform suppliers before implementation.
• Test the matching of periodic invoices in your system before going live.

The role of invoicing, ERP and accounting software

The standard defines the boundaries; your software determines what is practically feasible within those boundaries. Software choices are decisive on two points.

On the sending side: does your software support populating BT-132 (order line reference) and delivery periods at line level? Not all packages offer this as standard. Custom configuration or an additional integration may sometimes be required.

On the receiving side: can your customer’s system link multiple invoice lines to one purchase order, and does it process the periodic invoice automatically? A system expecting a strict one-to-one match (one invoice per order) will handle periodic invoices differently than intended.

If a supplier tells you that ‘collective invoices are not possible via Peppol’, it is worth asking whether the limitation comes from the standard or from the specific software implementation. Those two are not the same. Different software packages handle the possibilities offered by the standard in varying ways; comparing solutions on this point is worthwhile before making a choice.

Frequently asked questions

Can I send a monthly invoice via Peppol?

Yes. Sending a collective invoice via Peppol is possible, provided all deliveries or services to be invoiced trace back to a single purchase order or contract reference specified in BT-13 (Purchase Order Reference). You can specify the individual deliveries, periods, or services per invoice line. Whether this works in your specific situation also depends on the matching arrangements with your customer and the capabilities of the software used.

Can one Peppol invoice reference multiple purchase orders?

No. Peppol BIS Billing 3.0 and EN 16931 recognise only one Purchase Order Reference (BT-13) at invoice level, with cardinality 0..1. The standard provides no mechanism to consolidate multiple independent purchase orders in a single invoice. At line level, BT-132 references only a line number within the order specified in BT-13.

What is the difference between Buyer Reference (BT-10) and Purchase Order Reference (BT-13)?

BT-10 (Buyer Reference) is an internal routing number assigned by the buyer, intended for internal use — such as a cost centre, department, or project code. It is not a purchase order reference. BT-13 (Purchase Order Reference) is the identifier of the buyer’s purchase order. The standard requires that an invoice contains at least one of the two (BT-10 or BT-13), but they serve fundamentally different purposes and are not interchangeable.

My supplier says collective invoices cannot be sent via Peppol — is that correct?

Partly. Bundling multiple independent purchase orders into a single Peppol invoice does not fit within the standard. However, periodic invoicing based on a single contract or framework agreement — bundling multiple deliveries on one invoice — is possible. It is worth asking whether the limitation your supplier mentions comes from the standard itself or from the capabilities of the specific software.

How does 3-way matching work with periodic invoices?

In 3-way matching, the buyer’s AP system compares the invoice against the purchase order (BT-13) and the receipt confirmation or delivery note. If one invoice contains multiple lines each referencing a line number of the same purchase order via BT-132, a well-configured AP system can match this per line. This requires that the reference structure is consistent and that prior agreement has been reached on this approach. Not all AP systems support this automatically.

What should I do with delivery notes or periods on the invoice?

Delivery information and periods can be included at different levels. At invoice level, a delivery period can be included (BG-14 for the entire invoice). At line level, BG-26 provides space for delivery periods per invoice line, allowing you to specify which period each invoiced service relates to regardless of whether a specific order line reference is available. Verify that your software correctly supports these fields.

What can I do if my software does not properly support periodic invoicing?

There are three options. Ask your current software provider whether configuration options are available for BT-132 and delivery periods at line level. Consider a package that supports this functionality as standard — capabilities vary considerably between providers. Or agree with your customer to send a separate invoice per purchase order; in many sectors this is the most widely used and automation-optimal approach.

Would you like to see which solutions support different invoicing workflows? Check the Peppol.now comparison tool at peppol.now/overview-of-peppol-suppliers.

Conclusion

Periodic invoicing via Peppol is possible — but the term ‘collective invoice’ conceals an essential distinction. Sending a collective invoice via Peppol works when all deliveries or services to be invoiced trace back to a single contract reference or purchase order. Bundling multiple, independent purchase orders into a single invoice does not fit within the standard: the standard recognises one Purchase Order Reference per invoice (BT-13), and the order line reference at line level (BT-132) refers exclusively to lines within that same order.

Whether periodic invoicing works smoothly in your specific situation depends, beyond the standard, also on software capabilities on both sides and on the matching arrangements with your customer. Those arrangements are best made in advance — before the invoice flow goes live via Peppol.

Different software solutions support the capabilities of Peppol BIS Billing 3.0 to varying degrees. Comparing on this point can help in choosing a package that suits your desired workflow, without having to conclude that ‘it cannot be done via Peppol’.

Sources

• OpenPeppol — Peppol BIS Billing 3.0 specificatie, inclusief BT-13 en BT-132 definitie en cardinaliteiten: docs.peppol.eu/poacc/billing/3.0/bis/
• OpenPeppol — Peppol BIS Billing 3.0 syntaxdocumentatie UBL Invoice (BT-132 definitie: ‘An identifier for a referenced line within a purchase order’): docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/
• OpenPeppol — GitHub repository peppol-bis-invoice-3, ubl-invoice.xml (BT-10 / BT-13 cardinaliteit 0..1, regel PEPPOL-EN16931-R003): github.com/OpenPEPPOL/peppol-bis-invoice-3
• CEN — European standard EN 16931-1:2017 (semantic data model for core invoices; available free of charge from any CEN member), see list: CEN Community – List of members en de Nederlandse bestellink via het NEN: NEN-EN 16931-1:2017+A1:2019/C1:2020 en
• Europese Commissie — Registry of CIUS specifications and extensions: https://ec.europa.eu/digital-building-blocks/sites/spaces/EINVCOMMUNITY/pages/48763623/Registry+of+CIUS+Core+Invoice+Usage+Specifications+and+Extensions

Looking for a reliable e-invoicing solution that properly supports periodic invoicing and Peppol connectivity? On Peppol.now you can compare service providers supporting Peppol BIS Billing 3.0, EN 16931 compliance and multi-country e-invoicing. View the overview of reliable Peppol solutions and make an informed choice.