Peppol eInvoice Processing in Australia: An AP Workflow

For Peppol eInvoice processing in Australia, the cleanest AP design uses two intake lanes and one control model. Receive structured PINT A-NZ data through Peppol-connected software, process PDF or image invoices through a document-extraction lane, then normalise both outputs to a shared AP schema. Coding, GST review, duplicate checks, approvals and exception handling run against that combined dataset before payment.

The distinction matters because a Peppol eInvoice is data, not a picture of an invoice. Its fields arrive in a structured payload, so AP does not need OCR to discover the supplier, invoice number or amounts. A PDF, scan or phone image still has to be read and interpreted before those same fields can enter the workflow. Sending both through document capture would throw away the Peppol payload's native structure; treating every document as if it were structured would hide extraction uncertainty.

Native structure does not make a transaction payable by itself. A PINT A-NZ payload can satisfy the receiving system's technical checks while carrying the wrong purchase-order reference, an unexpected GST treatment or a duplicate of an invoice already received by email. Conversely, a correctly extracted PDF still needs the same supplier, coding and approval controls as its Peppol counterpart.

For Australian AP teams, the practical eInvoicing workflow is therefore a convergence model. Capture each source in the form in which it arrives, retain its provenance and validation result, and converge only after each lane has produced the fields AP needs. This lets an organisation receive Peppol eInvoices in Australia without building a parallel finance process that ignores the suppliers still using email and scans.

What belongs in the Peppol lane and the document lane

The structured lane begins outside the AP inbox. A supplier sends an invoice or credit note through its Peppol service provider; accredited access points carry the transaction to the buyer's Peppol-connected accounting package, ERP or AP platform. That receiving stack handles participant routing and the applicable PINT A-NZ syntax and profile checks. AP should preserve the resulting structured fields and the transaction reference supplied by that system.

The document lane begins wherever files still arrive: a shared mailbox, scanner, upload folder or mobile image. PDF, JPG and PNG invoices have no guaranteed machine-readable field structure, even when the PDF contains selectable text. They need document reading and extraction, followed by review where a value or layout is uncertain.

Invoice Data Extraction belongs only in this residual lane. A finance team can use it to extract structured data from residual PDF invoices, as well as JPG and PNG files, and download the results as Excel, CSV or JSON. Those fields can be aligned downstream with an export from the separate Peppol or accounting-system lane. The product does not ingest PINT XML, connect to the Peppol network, act as an access point, receive or issue eInvoices, or validate a Peppol profile. The spreadsheet, accounting package, ERP or AP platform is where the two outputs are consolidated.

Keep inbound receipt separate from document conversion, too. Guidance on how to convert a PDF invoice to Peppol PINT A-NZ in New Zealand addresses a supplier-side creation task in another market. The broader process to convert PDF invoices into structured eInvoices is also an outbound transformation. Neither is the job facing an Australian buyer whose access point already receives native Peppol data while other suppliers continue emailing documents.

This boundary assigns each failure to the system able to resolve it. A PINT validation failure goes back through the receiving software or access-point process. An unreadable scan or uncertain extracted value goes to the document review queue. A supplier, GST, coding or approval problem belongs to AP regardless of which lane supplied the data.

---

Normalise both outputs to a shared AP schema

The shared schema should describe what AP needs to make and evidence a decision, not mirror either source format. Map the receiving system's PINT A-NZ fields and the document extractor's columns into the same business names, data types and null rules.

Shared field	AP use	Normalisation decision
Supplier identity and ABN	Supplier verification and matching	Keep the legal name and ABN in separate fields; do not rely on a display name alone
Invoice number	Posting and duplicate detection	Preserve the original value and create a comparison form with inconsequential spacing or punctuation removed
Invoice date and due date	Period, ageing and payment scheduling	Use one agreed date format and retain a blank where a date was not supplied
Buyer or PO reference	Order matching and routing	Distinguish a purchase-order number from other buyer references
Currency, net amount, GST and total	Tax and amount checks	Store currency explicitly and use numeric fields with a defined decimal convention
Line items	Coding, matching and analysis	Agree whether the downstream grain is one row per invoice or one row per line item
Source channel	Control routing	Record Peppol or document intake as a controlled value
Source reference	Audit trace	Retain the Peppol transaction reference or the document filename and page reference
Validation status	Source-specific technical result	Keep Peppol profile status separate from document extraction status
Review status	AP decision state	Use controlled states with an owner and resolution, rather than free-text inbox notes

This gives the PINT A-NZ fields AP uses a clear business destination without turning the dataset into a copy of the technical specification. Preserve the identifiers received through each lane, then derive a canonical ABN or internal supplier key for matching; a Peppol participant identifier should not be assumed to be the supplier's ABN. The access point or receiving application remains responsible for interpreting the current PINT A-NZ profile. The mapping layer only decides, for example, which received value populates Supplier ABN or Buyer Reference in the shared record.

The document lane must produce the same shape. If the Peppol export calls a field Invoice Issue Date and the extraction export calls it Invoice Date, the import mapping resolves that difference once. It should also define what happens when a PDF has no PO number, when a currency is implicit, or when line-item totals do not reconcile to the header total. A blank value, a failed validation and an unresolved review are different states and should not collapse into one empty cell.

Credit notes need the same discipline. Record document type explicitly, retain the reference to the original invoice where available, and adopt one sign convention for amounts across both lanes. Otherwise, a positive credit in one export and a negative credit in another can pass through the combined dataset with opposite financial meanings.

Profile validity is not approval to pay

Technical validation answers whether the receiving system can accept and interpret a Peppol transaction under the applicable rules. Because the fields are structured, AP avoids uncertainties such as whether a character in the invoice number is a zero or the letter O, which label contains the total, or where a table column ends. That is a meaningful control improvement, but it is not a commercial approval.

A profile-valid eInvoice can still name the wrong buying entity, quote an obsolete purchase order, charge an unexpected amount or apply GST incorrectly. It can arrive before goods or services have been acknowledged, or after a supplier has already emailed a copy. AP still needs to check the supplier and ABN, match the order and receipt where applicable, assess the amounts and tax treatment, assign coding, route approval and evaluate fraud indicators.

Represent these as distinct control results. A useful record might show Peppol profile: passed, supplier match: passed, PO match: exception, GST review: pending and approval: not started. A single Valid flag obscures which test ran and encourages downstream automation to treat transport success as authority to pay. The document lane follows the same pattern, but its source-specific status also records extraction and review outcomes.

For GST, the shared schema should retain the evidence needed for review rather than infer that structured delivery guarantees tax validity. The detailed thresholds and required fields belong in the guide to Australian tax invoice and GST requirements; the mixed-lane workflow should consume those rules consistently for both sources. Exceptions such as a missing ABN, a total that does not reconcile, or GST shown where the supplier treatment is unexpected need the same owner regardless of channel.

BAS reconciliation happens after reviewed transactions have been coded and posted into the accounting process. A Peppol access point transports structured transactions, while a document extractor reads invoices; neither function determines the organisation's BAS treatment or submits a BAS. Keeping that boundary visible prevents a technical status from silently becoming a tax conclusion.

Detect duplicates across Peppol and email before payment

Duplicate checks must run after the two lanes converge. Checking the Peppol queue and email queue separately will not catch the most characteristic transition-period error: a supplier emails a PDF, then sends the same invoice through Peppol after following up on payment.

Build the primary comparison from normalised supplier identity or ABN, invoice number, invoice date and total amount. A purchase-order reference strengthens the match where it is available. Keep both the original invoice number and a comparison form so harmless differences in spaces, slashes, hyphens or letter case do not defeat the control. An exact supplier-plus-number match should be high confidence, while matching amount, date and PO with a slightly different number should enter review rather than be rejected automatically.

The exception record should link both source records and stop payment processing until AP identifies the authoritative transaction. The resolution should state whether the second item was a duplicate copy, a replacement, a corrected invoice or a separate valid charge. Preserve the rejected or superseded source and the reason for the decision; deleting it removes the evidence needed to explain why only one payable was created.

Credit notes require transaction-aware matching. A credit note should not be dismissed as a duplicate merely because it refers to the original invoice and carries the same supplier. Its document type, sign, credited amount and original-invoice reference need to be evaluated together. Likewise, a corrected invoice may keep the original invoice number while changing GST or totals. The workflow should hold both records, establish which version governs and prevent the earlier version from progressing.

These controls work only when every intake path supplies comparable data. A duplicate rule that reads an ABN from Peppol but compares it with an unnormalised supplier name from email will generate avoidable misses and false positives. The shared schema gives the matching engine consistent values; AP judgment resolves the small set of cases where the transaction history, not the field equality, determines the answer.

Put review effort where each lane is uncertain

The two lanes should feed one exception process without pretending their uncertainties are identical. In the Peppol lane, technical exceptions come from the receiving software: a failed profile check, an unrecognised participant or a missing required reference. Once the payload is accepted, AP review should concentrate on supplier identity, order and receipt matching, GST treatment, coding, approval and unusual commercial terms, not OCR confidence.

The document lane adds a different set of source questions. A low-quality scan may make an invoice number uncertain; an unfamiliar layout may contain two plausible totals; a multi-page invoice may be incomplete. Reviewers need the extracted value, the reason it was flagged and a direct route back to the source page, alongside the same supplier, GST, duplicate and approval checks applied to Peppol records.

Invoice Data Extraction can mark a specific extracted result as Review Needed when it requires manual verification. The warning explains what should be checked, and exported rows can include the source file and page number for cross-reference. This behaviour applies to PDF and image extraction only. It does not review PINT data, validate a Peppol transaction or approve an invoice for payment.

Make review status a controlled workflow field. At minimum, the record needs a state, an owner and a resolution that distinguishes corrected data from an accepted exception. A queue entry such as GST mismatch should identify the affected check and retain the evidence used to clear it. Free-text mailbox notes are difficult to report on and can leave a held invoice looking indistinguishable from one nobody has opened.

Track exception reasons by source channel. A rise in Peppol PO mismatches points to supplier onboarding or master-data problems; repeated missing pages and unreadable values in the document lane point to submission quality or capture rules. Measuring the causes, rather than the raw number of invoices reviewed, shows where a process change will remove recurring work.

---

Phase the workflow without waiting for every supplier

A mixed-channel design can be implemented before supplier adoption is complete. Sequence the work around control dependencies:

1. Map every current receipt channel and identify which system owns each source record.
2. Preserve native Peppol receipt and validation in the connected accounting, ERP or AP stack.
3. Agree the shared field names, data types, provenance fields and credit-note treatment.
4. Route residual PDFs and images through document extraction into that same schema.
5. Test cross-channel duplicates, GST exceptions, corrections and approvals with representative invoices and credit notes.
6. Report exception causes and use them to improve supplier onboarding, master data and document quality.

There is an economic reason to preserve the structured lane rather than render every transaction as a document. In a 2022 Deloitte Australia interview on invoice processing costs, Bruce Billson cited estimated processing costs of about A$31 for a paper invoice, A$28 for a PDF attached to email and just over A$9 for an eInvoice. Those are dated interview estimates, not a current benchmark or a Deloitte-authored cost study, but the size of the reported gap illustrates why native structured data should remain structured.

The two-lane model is transition architecture, not an argument for permanent channel fragmentation. Supplier onboarding can increase the share received through Peppol over time, while document extraction reduces manual entry for the invoices that have not moved. As the channel mix changes, the shared schema, duplicate logic and commercial controls remain stable.

Do not convert Peppol payloads back into PDFs merely to fit a familiar capture process, and do not postpone document automation until every supplier adopts eInvoicing. Capture according to source, normalise according to AP needs, and apply controls across the combined dataset.