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

To turn a PDF invoice into a PINT A-NZ eInvoice, first extract the supplier, buyer, NZBN, GST, invoice number, invoice date, line items, payment terms, and totals 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.

Peppol will not replace PDFs overnight. The immediate test is whether the invoice fields used 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 structured data.

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.

For planning, the two live dates matter most: in-scope agencies must be eInvoice-capable by 1 January 2026, and must require large suppliers to submit eInvoices by 1 January 2027. Use the remaining time for supplier master-data cleanup, access-point onboarding, mapping tests, and rejection handling with real invoice samples.

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.

Do not copy mappings between PINT A-NZ, PINT AU, and PINT-SG. New Zealand invoices need NZBN and New Zealand GST treatment; Australian and Singapore invoices use their own identifiers, tax rules, and validation profiles even though the files all sit in the wider Peppol and UBL family.

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: confirm the buyer, NZBN, purchase order, GST treatment, line amounts, totals, and payment terms; map the record to PINT A-NZ through the ERP, billing platform, or access-point tooling; validate before transmission; and retain source evidence 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 show whether a failure came from 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 supplier matching, duplicate detection, purchase order matching, approval routing, GST coding, exception handling, or payment reconciliation. AP also needs a path for emailed PDFs, scanned paper, supplier statements, credit notes, AU Peppol invoices, and non-Peppol overseas invoices.

Readiness should come down to four controls: inventory invoice flows by sender, buyer, channel, volume, and system owner; choose the access-point or ERP route for PINT A-NZ generation and receipt; assign owners for rejected eInvoices, duplicate alerts, tax-code disputes, and supplier corrections; and monitor post-go-live failures 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.