Convert PDF Invoices to Peppol PINT A-NZ (NZ Guide)

To convert a PDF invoice to Peppol PINT A-NZ, start by extracting the supplier, buyer, NZBN, GST, invoice number, invoice date, line-item, payment-term, and total fields from the source document. Those values then need to be normalised and mapped into the PINT A-NZ Billing BIS before the eInvoice is sent through a Peppol access point.

The timing matters. New Zealand agencies that send or receive more than 2,000 domestic trade invoices a year must be eInvoice-capable by 1 January 2026. By 1 January 2027, those agencies must require large suppliers to submit eInvoices, which means suppliers invoicing government need a working path from today's PDF process to valid PINT A-NZ UBL XML before the mandate reaches procurement and contract enforcement.

That path is not just "turn PDF into XML". A PDF invoice is a presentation format. PINT A-NZ is a structured eInvoicing format with required parties, identifiers, tax treatment, line amounts, totals, payment details, and business rules. The practical work is:

1. Extract the invoice data from the PDF.
2. Standardise dates, amounts, supplier names, NZBNs, GST numbers, and line items.
3. Map the cleaned data into the fields expected by PINT A-NZ Billing.
4. Validate the resulting UBL XML against Peppol and A-NZ rules.
5. Send or receive the invoice through a Peppol access point.
6. Reconcile exceptions back to the source invoice, supplier record, or mapping rule.

For most finance teams, the XML itself is not the everyday interface. Suppliers do not usually hand-code PINT A-NZ files. They use billing software, an ERP, or a Peppol service provider that creates the UBL message and transmits it over the network. The quality of that process still depends on the invoice data underneath it. If the PDF extraction misses a GST treatment, reads an old supplier name, drops a line item, or loses the connection to the source page, the later Peppol step inherits the problem.

Buyer-side AP teams face the same issue in reverse. Incoming Peppol UBL reduces the need to OCR native eInvoices, but AP will still receive emailed PDFs, paper scans, AU Peppol invoices, supplier statements, credit notes, and other documents outside the PINT A-NZ lane. The operating model has to cover both channels: structured eInvoices where the supplier is ready, and reliable extraction for legacy invoices where they are not.

The useful question is therefore not whether Peppol replaces PDFs overnight. It does not. The question is whether the invoice fields your organisation already depends on for approval, GST, payment, and reconciliation are clean enough to support PINT A-NZ when a government customer, agency AP team, or access point expects them in structured form.

Turn Rule 44 deadlines into a readiness schedule

The mandate is easier to manage as a schedule than as a legal headline. Government Procurement Rule 44 eInvoicing capability requires New Zealand agencies that receive or send more than 2,000 domestic trade invoices annually to be eInvoice-capable by 1 January 2026, and to require large suppliers to submit eInvoices by 1 January 2027.

For agencies, the 2026 date is the operational trigger. Their primary AP and AR systems need to receive or send eInvoices through Peppol where the invoice volume threshold applies. That is not only a software switch. It affects supplier records, approval routing, exception queues, payment controls, and how incoming invoice data is matched to purchase orders and contracts.

For suppliers, the 2027 date is the contract-risk trigger. A large supplier is not simply being asked to prefer Peppol. If it invoices an in-scope agency, the agency must require eInvoices. The procurement rule defines large supplier by reference to the Financial Reporting Act threshold: total revenue of the entity and subsidiaries, if any, exceeds NZD 33 million in each of the two preceding accounting periods. Suppliers near that threshold should avoid treating 2027 as a distant systems project, because Peppol testing, access-point onboarding, ERP configuration, and customer-specific acceptance checks all take time.

The surrounding dates shape the plan:

• 31 March 2022: central government agencies were already expected to be able to receive Peppol eInvoices.
• 15 May 2025: PINT A-NZ Billing became the format finance teams need to plan around, replacing the older A-NZ BIS 3.0 path for practical new implementations.
• 1 December 2025: the fifth edition of the Government Procurement Rules takes effect.
• 1 January 2026: in-scope agencies must be eInvoice-capable.
• 1 January 2027: those agencies must require large suppliers to submit eInvoices.

That sequence leaves a narrow testing window. By the time an agency starts enforcing supplier eInvoicing, supplier master data, access-point routing, invoice field extraction, tax mapping, validation, and rejection handling should already have been tested with real invoice samples.

Below-threshold suppliers are not outside the commercial effect of the rule. A supplier under the NZD 33 million threshold may not be directly mandated, but a government buyer that has invested in Peppol-capable AP will have a practical reason to prefer suppliers that can send clean eInvoices. Peppol readiness becomes part of supplier quality, even before it becomes a hard legal requirement for that supplier.

The field map that turns a legacy PDF into PINT A-NZ data

The weak point in many eInvoicing projects is not the Peppol network. It is the layer before it: whether the organisation can capture the invoice data accurately enough for a valid structured message. A tool that can extract invoice data from PDFs into structured fields sits upstream of the ERP or access point, turning source invoices into data that can be reviewed, mapped, and passed into the system that creates the PINT A-NZ UBL file.

Invoice Data Extraction is useful in that upstream role because it converts invoices and financial documents into Excel, CSV, or JSON. Users upload PDFs or image files, describe the fields they need in a natural-language prompt, and receive structured output. For Peppol preparation, the prompt can ask for invoice-level fields and line-item fields in the same run, with source file and page references retained so a reviewer can trace a mapped value back to the original document. The product should be treated as the extraction layer, not as the Peppol access point or XML transmitter.

The practical field map looks like this:

Source PDF area	Structured value to capture	Why it matters for PINT A-NZ
Supplier header or footer	Legal name, trading name if shown, NZBN, GST number, address	Identifies the supplier party and supports Peppol routing, GST treatment, and supplier matching
Buyer block	Buyer name, NZBN or customer identifier, address, purchase order reference	Identifies the customer party and supports matching to the buyer's AP and procurement records
Invoice header	Invoice number, issue date, due date, currency, document type	Supplies core document identifiers and date fields that validation rules expect
Line table	Description, quantity, unit price, line net amount, GST rate or treatment, line total	Feeds item-level UBL structures and tax calculations
Totals box	Subtotal, GST amount, rounding, total payable, amount due	Provides control totals that must reconcile to line and tax subtotals
Payment block	Bank account, payment terms, remittance reference	Supports payment processing and remittance matching
Source evidence	File name, page number, extraction notes	Lets AP or AR trace exceptions back to the original PDF

That map is deliberately more detailed than a generic "PDF to XML" conversion. PINT A-NZ Peppol invoice extraction is not only about reading text. The data has to be normalised into a form the downstream system understands. Dates need a consistent format. Amounts need decimal precision. Supplier names need to match master data. GST treatment needs to be expressed as a structured tax category, not just copied as whatever wording appears on the invoice.

The same discipline applies to New Zealand's invoice-content rules. The NZ taxable supply information requirements define the information a New Zealand GST invoice needs to carry, but PINT A-NZ makes that information machine-readable. If the original PDF lacks a required GST detail, or if the extraction process cannot distinguish a supplier GST number from a customer reference, the Peppol step cannot repair the missing compliance evidence by itself.

Source-page evidence is a practical control, not an audit luxury. When a validation error says the line total does not match the quantity and unit price, someone needs to find the page where the line appeared. When a supplier says the GST treatment was correct, AP needs to compare the structured value with the PDF. When a customer rejects an eInvoice because the purchase order reference is missing, AR needs to know whether the reference was absent from the original or lost during extraction.

Legacy PDF invoice transformation for Peppol therefore has two outputs. One is the structured data file the finance team can inspect, clean, and load. The other is confidence: a documented path from each PINT A-NZ field back to the invoice evidence that produced it.

NZBN and GST treatment are not optional mapping details

PINT A-NZ depends on party identity. In New Zealand, the NZBN is the practical Peppol participant identifier for organisations. If the supplier or buyer identifier is wrong, the problem is not cosmetic. It affects routing, matching, validation, and the confidence AP has that the invoice belongs to the supplier record being paid.

That makes NZBN work a master-data task, not an eInvoicing afterthought. Supplier onboarding should confirm the legal entity name, NZBN, GST registration status, invoice address, remittance details, and any branch or organisation-part detail that the ERP or access point needs. Buyer records need the same discipline on the receiving side. A finance team that already has a process to verify a supplier NZBN before paying an invoice is closer to Peppol readiness than a team that treats the NZBN as another optional supplier note.

The identifier also reduces avoidable exceptions. If a legacy PDF shows a trading name but the Peppol message carries a legal name and NZBN, AP needs to recognise that both refer to the same supplier. If the supplier has changed name, merged, or sent invoices from more than one business unit, a weak supplier record turns into duplicate checks, held payments, or rejected eInvoices. The best time to resolve that is before the first PINT A-NZ test file is sent.

GST mapping carries similar weight. A PDF invoice might describe GST in plain language, a line note, or a totals box. PINT A-NZ needs structured tax treatment that the receiving system can validate. For New Zealand invoices, the common mapping questions include:

• Standard-rated supplies at 15 percent GST.
• Zero-rated supplies, including exports and compulsory zero-rating property cases.
• Exempt supplies such as some financial services or residential rent.
• Out-of-scope items that should not be treated as taxable supplies.
• Reverse-charge treatment where the transaction requires it.

The point is not to turn the eInvoice project into a GST advice project. It is to make sure the tax treatment already decided by the business is captured in a way PINT A-NZ can carry. A line with the wrong GST treatment can affect tax subtotals, invoice totals, buyer GST coding, and validation. A totals-only PDF that does not expose line-level GST treatment may need extra review before it becomes a reliable structured eInvoice source.

Identity and GST errors are expensive because they travel. A malformed NZBN or mismatched GST code may first appear as a validation failure, then as an access-point rejection, then as a supplier query, and finally as a reconciliation delay. Clean mapping collapses that chain back to the source: the supplier record, the invoice field, or the tax rule that needs correction.

PINT A-NZ, PINT AU, and PINT-SG share a family, not the same rulebook

PINT A-NZ is part of the Peppol International invoice family, so it shares the broad shape of other PINT specifications: UBL XML, standardised parties, invoice lines, tax totals, payment details, and Peppol network transmission. That shared family helps software vendors and access points support more than one jurisdiction. It does not remove local configuration.

For cross-Tasman suppliers, the operational question is PINT A-NZ vs PINT AU. New Zealand invoice flows revolve around NZBN and New Zealand GST treatment. Australian flows revolve around ABN, AU GST treatment, and Australian identifier details. The two countries share a PINT A-NZ foundation in the Peppol context, but the business data still has to be right for the country of the transaction and the buyer's receiving rules.

The differences show up in ordinary invoice work:

• Participant identity: NZ supplier and buyer records need NZBN. AU records need ABN, with branch or identifier detail where the system requires it.
• GST treatment: NZ standard GST is 15 percent. AU GST is 10 percent. Zero-rated, exempt, and out-of-scope treatment is not interchangeable just because both messages use UBL.
• Master data: A shared-service team may have the same supplier trading across both countries, but the tax registration, legal entity, and routing details can differ.
• Validation: A file that is structurally valid UBL can still fail jurisdiction-specific rules if the identifier scheme, tax category, or required local field is wrong.

Teams operating in both markets should read the NZ work alongside Australia Peppol e-invoicing requirements, but the mapping should not be copied blindly from one country to the other. The useful control is a jurisdiction field in the process itself: which country does this invoice belong to, which participant identifier applies, which GST rules apply, and which PINT profile should the access point or ERP generate?

Singapore is a useful comparison for multi-country AP teams, not a substitute rulebook. PINT-SG also sits in the Peppol and PINT world, but it brings Singapore-specific identity and GST checks. A team that needs to validate Singapore PINT-SG invoices will deal with UEN and Singapore input GST concerns that do not belong in an NZ PINT A-NZ file.

The practical lesson is that Peppol readiness is partly global and partly local. The global layer is the network, UBL structure, access-point model, and consistent exchange of invoice data. The local layer is where AP and AR projects succeed or fail: identifiers, tax mappings, validation rules, buyer expectations, and the supplier records behind them.

Validate the XML before the access point rejects it

Validation is where a PDF-to-PINT workflow proves whether the data is usable. It is not a general quality check or a final glance at the invoice total. A PINT A-NZ XML invoice has to satisfy UBL structure, Peppol business rules, A-NZ requirements, and Schematron validation rules before an access point will transmit it cleanly.

A practical validation sequence looks like this:

1. Generate the PINT A-NZ UBL payload from the ERP, billing system, or access-point tooling.
2. Run validation against mandatory fields, code lists, tax totals, line totals, date formats, party identifiers, and Peppol envelope requirements.
3. Review any failures against the source data that fed the message.
4. Correct the extraction, supplier master data, mapping rule, or invoice source record.
5. Regenerate and retest the file before sending.

Common rejection causes are predictable. Missing or malformed NZBN is a routing and party-data problem. Wrong GST treatment is a tax-mapping problem. Invalid dates are usually normalisation problems. Line-total mismatches point to quantity, unit price, rounding, discount, or tax calculation issues. Missing party addresses and unsupported references usually point back to incomplete supplier or customer master data.

Those errors should not be handled as isolated transmission failures. If an access point rejects the same supplier's invoices repeatedly because the NZBN is missing, resending the XML is wasted effort. The supplier record needs to be fixed. If invoices fail because the GST subtotal does not reconcile with line-level GST, the mapping needs to separate taxable, zero-rated, exempt, and out-of-scope lines properly. If due dates and invoice dates are inconsistent across PDF formats, extraction rules or ERP import logic need tightening.

The feedback loop is important because the source of truth sits in more than one place. Some fields come from the PDF. Some come from supplier master data. Some are calculated by the ERP. Some are added by the access point. A good exception process records where the failed field came from, who owns the correction, and whether the fix should apply to one invoice, one supplier, or the whole mapping rule.

Receiving teams need validation discipline too, but the timing is different. Pre-send validation protects the supplier from rejected eInvoices. Receive-side validation protects AP from duplicate invoices, mismatched suppliers, unsupported references, and invoices that arrive through Peppol but still need human exception handling. Treat both as controls in the same invoice-processing workflow, not as separate technical chores.

Plan for dual-mode sending and incoming Peppol UBL

The 2027 supplier mandate will not remove every PDF invoice from New Zealand finance workflows. Government agencies, large suppliers, sub-threshold suppliers, private-sector buyers, Australian counterparties, and overseas vendors will move at different speeds. A realistic operating model assumes Peppol and legacy channels run together.

For suppliers, the send path should be treated as a controlled data flow:

1. Create or receive the invoice record in billing software, ERP, or another source system.
2. Confirm the buyer, NZBN, purchase order, GST treatment, line amounts, totals, and payment terms.
3. Map the record to PINT A-NZ through the ERP, billing platform, or access-point tooling.
4. Validate the XML before transmission.
5. Send through the Peppol access point.
6. Retain source evidence and exception notes for rejected, disputed, or corrected invoices.

Access-point selection should stay practical. The route needs to support PINT A-NZ, connect cleanly with the billing or ERP system, expose validation feedback in a form finance staff can act on, and preserve enough status history to resolve rejected or disputed invoices. A provider name matters less than whether the team can see where a failure occurred: source data, mapping, validation, transmission, or buyer-side processing.

For buyer-side AP, incoming Peppol UBL changes the intake mix. Native XML invoices reduce dependence on OCR for suppliers that send valid Peppol documents, but they do not remove AP controls. The receiving process still needs supplier matching, duplicate detection, purchase order matching, approval routing, GST coding, exception handling, and reconciliation to payments. It also needs a clear path for invoices that arrive outside Peppol: emailed PDFs, scanned paper, supplier statements, credit notes, AU Peppol invoices, and non-Peppol overseas invoices.

That dual-mode environment is where many teams under-plan. A supplier may send Peppol to an in-scope government agency, PDFs to smaller customers, and portal invoices to one large private buyer. An AP team may receive PINT A-NZ from one supplier, PINT AU from another, PDF invoices from long-tail vendors, and consolidated statements at month end. The controls need to recognise the channel before applying the process.

A workable readiness sequence is:

• Inventory invoice flows by sender, buyer, channel, volume, and system owner.
• Clean NZBN, GST, address, payment, and purchase order data in supplier and customer records.
• Define the extraction fields needed for legacy PDFs and scanned invoices.
• Choose the access-point or ERP route for PINT A-NZ generation and receipt.
• Test validation with real invoices, including credit notes and messy line-item examples.
• Define who owns rejected eInvoices, duplicate alerts, tax-code disputes, and supplier correction requests.
• Monitor exceptions after go-live rather than assuming a successful first send proves the process.

The teams best placed for the 2027 requirement are not the ones that start with XML as an abstract compliance project. They are the ones that understand their invoice data first: which fields exist, where they come from, which ones are unreliable, and how each one moves from source document to approval, GST, payment, and reconciliation.