Guides · 2026-07-30

PINT A-NZ e-invoice validation: what gets rejected, and why

A structured e-invoice fails differently from a PDF. There is no human at the other end to notice that a total looks wrong — a receiver's software either accepts the document or rejects it against a published ruleset, and by then it has already left your system.

Validation and transmission are different problems

It is worth separating these early, because conflating them leads people to think they need an Access Point before they can do anything. A Peppol Access Point moves documents across the network. Validation asks a narrower question: does this document satisfy the ruleset the receiver will apply? You can answer that on your own machine, before choosing a provider, and before sending anything.

The practical consequence is that validation belongs in your build pipeline, not at the network edge. A rule failure is a bug in whatever generated the document, and bugs are cheapest to fix where they are written.

The four families of failure

Across the PINT A-NZ ruleset, the failures that actually occur cluster into four groups. Arithmetic dominates, which surprises people who expect e-invoicing problems to be exotic.

Arithmetic that does not reconcile

The largest group by far, and the least glamorous. Sum of line net amounts must equal the document line-extension total; tax-exclusive plus tax must equal tax-inclusive; payable must account for prepayments and rounding. These fail when a system rounds per line and totals from unrounded values, or when a discount is applied at the header without being reflected in the allowance total.

Aligned with EN 16931 BR-CO-10, BR-CO-13, BR-CO-15, BR-CO-16

Missing specification identity

A PINT A-NZ document has to say what it is. Without a specification identifier the receiver cannot know which ruleset to apply, so it is a mandatory field rather than metadata. A generic EN 16931 identifier where PINT A-NZ is expected is the common near-miss.

Aligned with EN 16931 BR-01

Australian identifiers that do not check out

An ABN carried as a scheme-0151 identifier must pass the ATO mod-89 checksum. A transposed pair of digits produces a number that looks entirely plausible and fails validation at the receiver — which is exactly the sort of error a human review never catches.

Aligned with A-NZ scheme 0151

Dates and codes in the wrong shape

Dates must be ISO YYYY-MM-DD, not local format. Invoice type codes come from UNTDID 1001, and tax category codes from the A-NZ set (S, Z, E, G, O). These are cheap to get right and cheap to check, which is why they belong in an automated gate rather than a checklist.

Aligned with EN 16931 BR-03, BR-04; UNTDID 1001

Why rounding causes most of the arithmetic failures

EN 16931 expects monetary amounts at two decimal places, and the totals to reconcile at two decimal places. A system that computes line amounts at full precision, sums those, and then rounds the total will disagree with one that rounds each line first — by a cent or two, which is enough to fail a strict receiver.

The fix is not a looser tolerance; it is deciding where rounding happens and doing it consistently. A validator that reports the two numbers it compared — “lines sum to 149.00, document says 150.00” — tells you immediately which side drifted, where a bare pass/fail leaves you guessing.

What a useful validation report contains

“Invalid” is not actionable. A report worth integrating gives you, for every problem: a stable rule identifier you can log and branch on, the standard rule it corresponds to so the finding can be traced back to EN 16931 or PINT rather than taken on trust, a severity that distinguishes must-fix from should-fix, and the element path so a fix goes to the right line instead of starting a search.

It should also be deterministic. Validation is a rules problem, not an inference problem — the same document should produce the same report every time, and a report that varies between runs cannot be used as a gate.

Frequently asked

What is PINT A-NZ?

PINT A-NZ is the Australia–New Zealand billing specification for Peppol e-invoices. It builds on the European EN 16931 semantic model and adds local rules — ABN identifiers under scheme 0151, GST categories, and the 10% standard rate. An invoice that satisfies generic UBL can still fail PINT A-NZ.

Why do Peppol e-invoices get rejected?

Most rejections are arithmetic rather than exotic: line amounts that do not sum to the document total, a tax-inclusive amount that is not the exclusive amount plus tax, or a payable amount that ignores a prepayment. After that come missing specification identifiers, dates that are not ISO YYYY-MM-DD, and ABNs that fail their checksum.

What is the difference between an error and a warning?

An error means the rule is mandatory and a compliant receiver may reject the document. A warning means recommended practice, or a check where rounding conventions legitimately differ between senders. Only errors should block a send; treating warnings as blockers creates busywork.

Do I need a Peppol Access Point to validate an e-invoice?

No. Validation and transmission are separate concerns. An Access Point sends and receives documents on the Peppol network; a validator only reads a document and reports whether it conforms. You can validate before you have chosen an Access Point at all.

Is e-invoicing mandatory in Australia?

Not for business-to-business trade. Commonwealth agencies have adopted Peppol for procurement and have their own timelines, which pulls their suppliers along, and over 400,000 Australian businesses are already reachable on the network. Treat it as a strong tailwind rather than a legal deadline.