Demo: 2026 Global eInvoicing Compliance in Oracle

• 0:06 — Supported countries and mandates — Overview of which countries APRO can support for e-invoicing versus which currently have a mandate. The Netherlands has no mandate but uses Peppol, while Italy and Poland are handled, and a mandate for smaller companies is noted for 1 April.
• 0:38 — Mandate timeline by country — Singapore and Belgium are already live, with Belgian customers using APRO for AP processing over Peppol. Poland follows within a week or two, then Slovenia, France, the United Arab Emirates and the Philippines — some via Peppol, some via government portals.
• 1:57 — Four-corner vs five-corner models — Explanation of the difference between the four-corner Peppol model and the five-corner government model. Within government models, some only return an acknowledgement while others, such as France and Poland, forward the invoice to the buyer and return a reference number.
• 2:15 — APRO platform and AR exception handling — The platform covers both accounts receivable and accounts payable, connects directly to Oracle, and validates against Oracle master data. Where data is missing or inconsistent — such as an e-invoicing identifier that does not match the tax number — an error is raised and the invoice can be refetched from a workbench.
• 3:28 — AP intake, matching and validation checks — Inbound XML invoices are fetched by email or pull, checked against Oracle master data, and matched to supplier sites by PO number, VAT number or IBAN. PO and non-PO matching is supported by rules, additional checks can stop invoices with unknown IBANs or bank accounts, and both PDF and XML are attached in Oracle.
• 4:50 — Accounts receivable outbound flow — Data is pulled from Oracle, converted to XML, and sent via Peppol, email, SFTP or a government portal. Customer site attributes determine the send method, format and e-invoicing identifier, and a transaction-level status attribute shows whether an invoice is sent, in progress, complete or not yet picked up.
• 5:51 — AI agents, assistant and banking — Planned AI capabilities include automatic PO matching without setup and an AI assistant that answers product configuration questions in place of the help desk. The existing banking solution handles global payments and automatic bank statement reconciliation, with rule-free reconciliation planned during 2026.
• 7:53 — PO matching screen and AI assistant — Walkthrough of the AP user interface for invoices that could not be posted straight to Oracle or that require a check first, showing invoice lines and the marked fields used for PO matching. The AI assistant is shown answering how to set up a new user.
• 8:41 — Demo start: AR transactions in APRO — The demo opens in the APRO menu, which resembles Oracle’s own interface. Searching by transaction date shows a completed AR transaction where both a PDF and the APRO-generated XML are attached back onto the Oracle transaction.
• 9:58 — Scheduled sending and the AR workbench — A scheduled process fetches completed transactions from a given transaction source; it can run every five minutes but once a day is often suggested depending on volume. The AR workbench holds stuck invoices, including those waiting hours or up to half a day for a government acknowledgement file.
• 12:10 — Stuck invoice reasons and validation — Examples of stuck invoices include missing mandatory XML fields such as tax amount and tax-inclusive amount, waiting on a third party, no acknowledgement file returned, and lost connections to a government portal. Clicking validate removes the invoice from the workbench and retries the send.
• 13:49 — History: Peppol vs government portal — The history tab shows completed invoices. A Peppol send displays the message and a track-and-trace of steps ending at a destination Peppol ID, while a Polish government send returns a reference number plus the official Polish XML invoice and a downloadable acknowledgement file. Rejections are shown in the application and return the invoice to the workbench.
• 15:56 — AP demo: imports and workbench — The AP module includes a document rejection manager that can automatically return invoices to suppliers when a PO is missing or the invoice is a duplicate, and an import overview covering Peppol, SFTP and email connections. The workbench shows the XML data next to the embedded PDF, and clicking validate runs the checks before posting to Oracle.
• 19:10 — Hybrid PDF/XML invoice and PO matching — A hybrid invoice — a PDF with XML embedded — is processed without OCR because the data comes from the XML. APRO had already found and matched the PO line and derived the code combination; the invoice was held only because automatic posting to Oracle was disabled.
• 20:11 — Reference numbers, payments and Oracle result — The government portal reference number is captured into a separate attribute so the APRO banking gateway can use it as the payment reference, which is required for Polish invoices. One invoice remains stuck because the PO in the XML does not exist in Oracle, and the processed invoices are shown validated and ready for payment in Oracle Payables with both PDF and XML attached.

Which countries and mandates does the APRO e-invoicing solution cover?

Support extends beyond countries that currently have a mandate. Singapore is already live and Belgium is now live, with Belgian customers using the platform for AP processing over Peppol. Poland was described as going live within a week or two, with an additional deadline of 1 April noted for smaller companies. Slovenia, France, the United Arab Emirates and the Philippines were named as the following mandates. The Netherlands has no mandate but Peppol is still used there, and Italy and Poland are also supported. Some of these countries operate through Peppol and others through government portals.

What is the difference between the four-corner and five-corner e-invoicing models?

The four-corner model is the Peppol arrangement, where the invoice travels between the sender and receiver through network access points. The five-corner model routes through a government platform. Government implementations differ from each other: in some, the government only returns an acknowledgement that the invoice was received, and the supplier still has to deliver the invoice to the customer. In others, such as France and Poland, the government platform sends the invoice on to the buyer and returns a reference number that is also communicated to the buyer, confirming that a valid invoice was submitted.

How does the accounts receivable side work with Oracle?

A scheduled process pulls completed transactions from Oracle from a defined transaction source and generates an XML file. The send channel — Peppol, email, SFTP or a government portal — along with the required format and the e-invoicing identifier are configured as attributes at the customer site level, so the system knows how to transmit each invoice. A status attribute at transaction level shows whether an invoice has been sent, is in progress, is done, or is empty and therefore not yet picked up. Once sent, the generated XML is attached back onto the Oracle AR transaction alongside the PDF. The scheduled process can run as often as every five minutes, though once a day is often sufficient depending on transaction volume.

How are incoming supplier invoices processed on the accounts payable side?

XML invoices are collected from channels including Peppol, email and SFTP, then pulled into the platform. The data is checked against Oracle master data, with the supplier site identified using the PO number, VAT number, IBAN or other details. Invoice lines are automatically matched against PO information where a PO applies, and where there is no PO, rules define which accounting strings the invoice should be booked to. Additional validation checks can be activated — for example, stopping an invoice when the XML contains an IBAN or bank account that is not known in Oracle — and the AP user is told why. When the invoice is posted to Oracle, both the PDF and the original XML are transferred as attachments.

What happens when an invoice cannot be processed?

Both the AR and AP sides have a workbench listing invoices that are stuck, showing the reason. On the outbound side, reasons include mandatory XML fields that could not be populated — such as the tax amount and the tax-inclusive amount — waiting on a third party to pick up the information, no acknowledgement file being returned by the government, a lost connection to a government portal, or the XML file simply not being creatable. Clicking validate removes the invoice from the workbench and retries sending it. On the inbound side, a common cause is a PO number in the XML that does not exist in Oracle, and another is the absence of a daily exchange rate for the currency being imported. Invoices that fail during creation in Oracle are routed back with an explanation.

What is the difference between what you get back from Peppol versus a government portal?

With Peppol, confirmation arrives as an API message indicating everything is fine, but there is no visible acknowledgement file; the history view shows the Peppol message and a track-and-trace of the steps taken, ending at the destination Peppol ID. With government portals, actual XML acknowledgement files are returned and displayed in the application, and they can be downloaded and checked. For Poland, a reference number is returned along with two attachments: the official Polish XML invoice and the acknowledgement file confirming the submission was accepted. Acknowledgements from a government portal can take one to three hours, or even half a day, to arrive. If an acknowledgement is a rejection, the reason is shown and the invoice appears in the workbench rather than in history.

Why does the Polish reference number matter for payments?

When a Polish invoice is paid, the reference number issued by the government portal must be quoted in the payment reference field — the payment remittance ID. The platform picks that number up from the incoming invoice and can place it in a separate attribute field. The banking gateway then reads that attribute and uses it as the payment reference, so the payment is made in the legally required form and avoids penalties from the government for doing it incorrectly. This mapping is applied on both the imaging and banking sides so the whole purchase-to-pay process is handled in one system.

What AI functionality was described, and when is it expected?

Three items were described as in progress. An AI agent for automatic PO matching was said to be ready during the year and at the end of Q1; rule-based PO coding already exists but sometimes needs setup to match PO lines to invoice lines correctly, whereas the agent is intended to work without setup by determining how to book the invoice from the PO number found in the XML. An AI assistant, described as almost done, functions as an in-product manual, answering questions such as how to set up a user by explaining the steps, the menu screens involved and the authorizations to assign, reducing the need to contact the help desk. Separately, automatic bank reconciliation without rule setup was described as an upcoming release within 2026, replacing the current rule-based statement matching.

How are hybrid PDF-with-embedded-XML invoices handled?

An invoice that is a PDF with XML embedded inside it is processed from the embedded XML data rather than by reading the image, so no OCR runs against it and the invoice text itself is not used. In the example shown, the platform located the PO, matched it to the correct line based on the invoice information, and derived the code combination from the PO. The invoice only remained in the workbench because automatic posting to Oracle had been disabled for the demonstration; otherwise it would have gone straight through.