0:06 — Session overview and presenter — The session opens with the agenda: an introduction to e-invoicing, how e-invoicing combines with banking, and a demonstration processing two XML invoices into Oracle, creating a payment batch, picking it up on the banking side and sending the payment file to the bank. The presenter introduces himself as Peter, with almost ten years at Apro and prior experience in Oracle E-Business Suite and Oracle Cloud. 1:00 — Why e-invoicing — Explains the core benefits of e-invoicing: XML removes the need to OCR invoices and can be mapped to the right Oracle tables and fields, and formats are standardised either as a UBL standard or as a country-specific format. Some countries additionally require real-time reporting to the government or a signature for an invoice to be valid. 1:57 — Global adoption and business impact — Covers the worldwide spread of e-invoicing mandates, including Belgium moving to both AP and AR business-to-business next year, widespread business-to-government use in Europe, and Italy where invoices have been exchanged through a government portal for several years. The practical impact on a business includes connecting to portals, using a Peppol service provider, integrating with Oracle for AP and AR, and having somewhere to view acknowledgements for both invoices and payments. 3:11 — Mandate timeline: 2025 and 2026 — Walks through the mandate calendar. Germany started on the AP side in 2025, requiring the XML file to be processed rather than only the PDF, with Malaysia, Singapore, Slovakia and China preparing mandates. Belgium, France, Spain and Poland are listed for 2026, though Spain's timeline was described as still unclear. 3:57 — Manual payment problems — Describes the friction in manual payment handling: checking that a payment batch uses the correct format for the bank, having to remove the format and rebuild the batch when something is wrong, invoices being paid late, and the resulting staff frustration and IT involvement when a company works with multiple banks and payment formats. 4:56 — Banking capabilities and approvals — Outlines the banking side: more than 1,900 banking formats in total including bank statement formats, of which around 1,600 are payment formats, plus rejection handling that shows the bank's acknowledgement and which transactions were rejected and why. Built-in approvals can be tiered by amount — for example one approver above €500 and three approvers for a batch of a million — or bypassed entirely for a fully automated flow, and a rejected transaction can be voided with the status updated back in Oracle. 6:46 — Process flow diagram — Summarises the flow visually: invoices and payment batches are picked up from Oracle, the correct format is created and sent to the bank, and the bank returns an acknowledgement file over the same host-to-host or SFTP connection, which is then visible in the dashboard. 7:12 — Demo: importing e-invoices — The demo starts in the application, showing the AP invoice automation area and the import overview, where each line is a run containing a batch of picked-up invoices. A scheduled process checks each government portal and Peppol connection on a configurable interval, PDF invoices can be fetched from a connected email account, and the presenter triggers the import manually to pull in two Italian invoices whose FatturaPA XML format is recognised. 9:59 — Invoice history and revalidation queue — The invoice history screen tracks what happened to each individual invoice, showing two invoices done and approved in Oracle Fusion and ready for a payment batch, plus two waiting in the revalidation queue because they could not be sent straight through. 10:57 — Pre-validation checks and dummy PDF — Explains why an invoice is held: the invoice number already existed in Oracle, one of several up-front checks that also cover cases such as a bank account on the invoice that is not present in the Oracle system. Because Italian invoices usually contain no PDF inside the XML, a dummy PDF is generated so the content is visible during approval and payment, and the presenter corrects the invoice number and saves and validates. 12:10 — Supplier recognition, PO matching and accounting rules — The next queued invoice shows an invoice recognition score below 100 percent, which the presenter says disappears after a few invoices from the same supplier site. He notes that nothing gets stuck inside Oracle because pre-checks happen first, that invoice lines from the XML support automatic PO matching, and that accounting rules per supplier site can build the correct code combination from XML header values, line values, or both for non-PO invoices. 14:05 — Invoice record in Oracle — Both invoices move to Oracle and the invoice history is refreshed to confirm their status. Opening the invoice in Oracle shows it created with two attachments — the generated dummy PDF and the original XML from the portal — so approvers in the Oracle approval process can read a PDF rather than raw XML. 15:54 — Submitting the payment process in Oracle — With the invoice validated, the presenter moves to payments in Oracle and resumes a pre-prepared payment process request rather than scheduling it. The invoices awaiting payment are shown per supplier site with their invoice numbers, and resuming the process makes the batch ready to be picked up. 17:16 — Payment batch approval — In the payments workbench, a scheduled process fetches new payment batches and checks whether the amount requires approval. The demonstrated batch needs approval because it exceeds €500, and approval must be given per line or applied to the batch as a whole. 18:38 — Creating and inspecting the payment file — Once approved, the batch moves to file creation, where a scheduled process builds the correct banking format and would normally send it to the bank automatically. The presenter runs file creation manually; because there is no test connection to a bank, the completed payment file is written to an SFTP drive, where it can be downloaded and inspected. 19:59 — Acknowledgement file handling — To demonstrate the return leg, the presenter places an acknowledgement file on the SFTP queue as though the bank had sent it back reporting a rejected payment. The file is picked up and the acknowledgement history shows the acknowledgements for a period, including one payment rejected because of an invalid IBAN. 22:29 — Voiding a rejected payment back to Oracle — The rejection is also visible in the supplier payment history alongside the batch and its downloadable invoice images. The rejected transaction is voided through a direct API to Oracle, voiding is only possible where the bank actually returned a rejection, the voided status is confirmed in Oracle's Manage Payments screen, and the transaction can then be included in a new payment batch.

Home / Resources / Webinars

Demo: Full Invoice to Pay in Oracle Financials

Key takeaways

Apro (referred to as "April" by the automatic transcription) is demonstrated processing two Italian e-invoices from XML into Oracle Fusion, then creating and approving a payment batch and generating the bank payment file.
E-invoicing removes the need to OCR incoming invoices because the XML data can be mapped directly to Oracle tables and fields, and mandates are expanding country by country — Germany's AP-side requirement started in 2025, with Belgium, France, Poland and (less certainly) Spain following in 2026.
The banking side supports more than 1,900 bank formats in total, of which roughly 1,600 are payment formats, plus rejection handling and acknowledgement files returned from the bank over host-to-host or SFTP connections.
Pre-validation checks run before an invoice reaches Oracle — duplicate invoice numbers, unknown supplier bank accounts and similar issues are caught in the Apro workbench so nothing gets stuck inside the Oracle interface.
For Italian invoices that arrive as XML without a PDF, a dummy PDF is generated and attached in Oracle alongside the original XML, so approvers can see what they are approving.
Payment batches can be routed through amount-based approval rules (for example, batches above €500 need one approver) or run fully automatically from Oracle pickup to bank delivery.
When a bank acknowledgement reports a rejected transaction, that single payment can be voided in Apro and the void status is pushed back to Oracle through an API so the invoice can be included in a later payment run.

Overview

This session, presented by Peter — an Apro employee of almost ten years with a background in Oracle E-Business Suite and Oracle Cloud — covers end-to-end invoice-to-pay processing for Oracle Financials. The stated plan for the session is to explain e-invoicing, explain how e-invoicing combines with banking, and then demonstrate two XML invoices being processed into Oracle, a payment batch being created, that batch being picked up on the banking side, and the resulting payment file being sent to the bank.

The opening explains why e-invoicing matters. Because an invoice arrives as XML rather than a scanned document, OCR is no longer required and the XML fields can be mapped to the corresponding Oracle tables and fields. Formats are standardised — either a UBL-style standard or a country-specific format — and some jurisdictions add real-time reporting to the government or a signature requirement for an invoice to be valid. Adoption is described as global and still growing: Germany began requiring AP-side XML processing in 2025, with Malaysia, Singapore, Slovakia and China working on mandates; Belgium, France and Poland are named for 2026, with Spain also expected in 2026 although its timeline was described as still unclear. Italy is cited as a market where e-invoicing through a government portal has been in routine use for several years. The practical consequences for a business are connections to portals, a Peppol service provider, an integration with Oracle for AP and AR, and somewhere to view acknowledgements confirming whether an invoice or a payment was accepted.

The payments discussion focuses on what goes wrong when payment files are handled manually: checking that the format matches the bank, having to remove a format and rebuild a payment batch when the bank rejects it, invoices paid late, staff frustration and heavy IT involvement when multiple banks and formats are in play. Against that, the product side is described as more than 1,900 banking formats — a figure that includes bank statement formats, with roughly 1,600 of them payment formats — along with rejection handling that surfaces the bank's acknowledgement file and shows which transactions were rejected and why, and built-in approval rules that can be tiered by amount (a batch above €500 needing one approver, a batch of a million needing three) or switched off entirely for a fully automated flow.

The demonstration begins by importing invoices. A scheduled process polls each government portal and Peppol connection on a configurable interval, and PDF invoices can also be collected from a connected email account; the presenter triggers the import manually to show two Italian invoices being fetched and their XML format (FatturaPA) recognised. The invoice history screen tracks each invoice individually. Two invoices required revalidation in the Apro workbench: one had an invoice number already present in Oracle, illustrating the up-front duplicate check, and the second showed a supplier-site recognition confidence below 100 percent, which the presenter said fades away once a few invoices from that supplier site have been processed. He also showed the generated dummy PDF for the Italian XML invoices, PO matching driven by the XML invoice lines, and accounting rules per supplier site that build code combinations from XML header or line values for non-PO invoices. After saving and validating, both invoices reached Oracle, where the invoice record carries two attachments — the dummy PDF and the original XML from the portal.

The final part runs the payment. In Oracle, the presenter resumes a prepared payment process request so the batch becomes available for pickup. On the Apro side, a scheduled process fetches new payment batches, checks the amount against the approval rules, and the demonstrated batch required approval because it exceeded €500; approval had to be given per line or on the batch as a whole. Once approved, the batch moved to file creation, where the correct banking format is produced and would normally be transmitted to the bank — in this environment there was no test bank connection, so the completed file landed on an SFTP drive and was opened for inspection. To show the return leg, the presenter placed an acknowledgement file on the SFTP queue as though the bank had returned it. The acknowledgement was picked up and the acknowledgement history showed one payment rejected for an invalid IBAN. That rejection also appears in the supplier payment history, where the invoice images can be downloaded and the individual transaction can be voided; voiding is only permitted for transactions the bank actually rejected. The void was then confirmed in Oracle's Manage Payments screen, and the presenter noted the voided transaction can be included in a new payment batch.

Chapters

0:06 — Session overview and presenter — The session opens with the agenda: an introduction to e-invoicing, how e-invoicing combines with banking, and a demonstration processing two XML invoices into Oracle, creating a payment batch, picking it up on the banking side and sending the payment file to the bank. The presenter introduces himself as Peter, with almost ten years at Apro and prior experience in Oracle E-Business Suite and Oracle Cloud.
1:00 — Why e-invoicing — Explains the core benefits of e-invoicing: XML removes the need to OCR invoices and can be mapped to the right Oracle tables and fields, and formats are standardised either as a UBL standard or as a country-specific format. Some countries additionally require real-time reporting to the government or a signature for an invoice to be valid.
1:57 — Global adoption and business impact — Covers the worldwide spread of e-invoicing mandates, including Belgium moving to both AP and AR business-to-business next year, widespread business-to-government use in Europe, and Italy where invoices have been exchanged through a government portal for several years. The practical impact on a business includes connecting to portals, using a Peppol service provider, integrating with Oracle for AP and AR, and having somewhere to view acknowledgements for both invoices and payments.
3:11 — Mandate timeline: 2025 and 2026 — Walks through the mandate calendar. Germany started on the AP side in 2025, requiring the XML file to be processed rather than only the PDF, with Malaysia, Singapore, Slovakia and China preparing mandates. Belgium, France, Spain and Poland are listed for 2026, though Spain's timeline was described as still unclear.
3:57 — Manual payment problems — Describes the friction in manual payment handling: checking that a payment batch uses the correct format for the bank, having to remove the format and rebuild the batch when something is wrong, invoices being paid late, and the resulting staff frustration and IT involvement when a company works with multiple banks and payment formats.
4:56 — Banking capabilities and approvals — Outlines the banking side: more than 1,900 banking formats in total including bank statement formats, of which around 1,600 are payment formats, plus rejection handling that shows the bank's acknowledgement and which transactions were rejected and why. Built-in approvals can be tiered by amount — for example one approver above €500 and three approvers for a batch of a million — or bypassed entirely for a fully automated flow, and a rejected transaction can be voided with the status updated back in Oracle.
6:46 — Process flow diagram — Summarises the flow visually: invoices and payment batches are picked up from Oracle, the correct format is created and sent to the bank, and the bank returns an acknowledgement file over the same host-to-host or SFTP connection, which is then visible in the dashboard.
7:12 — Demo: importing e-invoices — The demo starts in the application, showing the AP invoice automation area and the import overview, where each line is a run containing a batch of picked-up invoices. A scheduled process checks each government portal and Peppol connection on a configurable interval, PDF invoices can be fetched from a connected email account, and the presenter triggers the import manually to pull in two Italian invoices whose FatturaPA XML format is recognised.
9:59 — Invoice history and revalidation queue — The invoice history screen tracks what happened to each individual invoice, showing two invoices done and approved in Oracle Fusion and ready for a payment batch, plus two waiting in the revalidation queue because they could not be sent straight through.
10:57 — Pre-validation checks and dummy PDF — Explains why an invoice is held: the invoice number already existed in Oracle, one of several up-front checks that also cover cases such as a bank account on the invoice that is not present in the Oracle system. Because Italian invoices usually contain no PDF inside the XML, a dummy PDF is generated so the content is visible during approval and payment, and the presenter corrects the invoice number and saves and validates.
12:10 — Supplier recognition, PO matching and accounting rules — The next queued invoice shows an invoice recognition score below 100 percent, which the presenter says disappears after a few invoices from the same supplier site. He notes that nothing gets stuck inside Oracle because pre-checks happen first, that invoice lines from the XML support automatic PO matching, and that accounting rules per supplier site can build the correct code combination from XML header values, line values, or both for non-PO invoices.
14:05 — Invoice record in Oracle — Both invoices move to Oracle and the invoice history is refreshed to confirm their status. Opening the invoice in Oracle shows it created with two attachments — the generated dummy PDF and the original XML from the portal — so approvers in the Oracle approval process can read a PDF rather than raw XML.
15:54 — Submitting the payment process in Oracle — With the invoice validated, the presenter moves to payments in Oracle and resumes a pre-prepared payment process request rather than scheduling it. The invoices awaiting payment are shown per supplier site with their invoice numbers, and resuming the process makes the batch ready to be picked up.
17:16 — Payment batch approval — In the payments workbench, a scheduled process fetches new payment batches and checks whether the amount requires approval. The demonstrated batch needs approval because it exceeds €500, and approval must be given per line or applied to the batch as a whole.
18:38 — Creating and inspecting the payment file — Once approved, the batch moves to file creation, where a scheduled process builds the correct banking format and would normally send it to the bank automatically. The presenter runs file creation manually; because there is no test connection to a bank, the completed payment file is written to an SFTP drive, where it can be downloaded and inspected.
19:59 — Acknowledgement file handling — To demonstrate the return leg, the presenter places an acknowledgement file on the SFTP queue as though the bank had sent it back reporting a rejected payment. The file is picked up and the acknowledgement history shows the acknowledgements for a period, including one payment rejected because of an invalid IBAN.
22:29 — Voiding a rejected payment back to Oracle — The rejection is also visible in the supplier payment history alongside the batch and its downloadable invoice images. The rejected transaction is voided through a direct API to Oracle, voiding is only possible where the bank actually returned a rejection, the voided status is confirmed in Oracle's Manage Payments screen, and the transaction can then be included in a new payment batch.

Questions this webinar answers

What is demonstrated end to end in this session?

Two Italian XML e-invoices are imported from a portal, validated and pushed into Oracle Fusion, a payment process request is submitted in Oracle, the resulting payment batch is picked up and approved on the banking side, the bank payment file is created, and a returned bank acknowledgement showing a rejected payment is used to void that single transaction back in Oracle.

Why does e-invoicing remove the need for OCR?

An e-invoice arrives as a structured XML file rather than a scanned image or PDF, so the values can be read directly from the XML and mapped to the corresponding Oracle tables and fields. There is no character recognition step because the data is already machine-readable.

Which countries have e-invoicing mandates coming into effect?

Germany started on the AP side in 2025, meaning a received XML invoice must be processed rather than only the PDF, and Malaysia, Singapore, Slovakia and China were described as working on mandates. Belgium, France, Spain and Poland are due in 2026, with Belgium covering both AP and AR for business-to-business, though the Spanish timeline was described as still unclear. Italy has had e-invoicing through a government portal in routine use for several years.

How many bank formats are supported?

More than 1,900 banking formats in total, a figure that includes bank statement formats as well as payment formats. Roughly 1,600 of those are payment formats, which was described as enough coverage to pay any bank in the world in the correct format.

What happens when an invoice cannot be sent straight to Oracle?

It waits in a revalidation queue in the Apro workbench rather than being pushed into Oracle. Pre-validation checks run up front — for example detecting an invoice number that already exists in Oracle, or a bank account on the invoice that is not present in the Oracle system — so an operator can correct the invoice and then save and validate it. The stated result is that an invoice is either sitting in the workbench or already validated in Oracle Payables, and nothing gets stuck part-way inside the Oracle interface.

How are Italian XML invoices made readable for approvers?

Italian invoices typically do not include a PDF inside the XML file, so a dummy PDF is generated from the XML content. In Oracle the invoice then carries two attachments — that generated PDF and the original XML from the portal — so anyone in the Oracle approval process can open a readable PDF instead of having to interpret raw XML.

How are payment batches approved?

A scheduled process fetches new payment batches from Oracle and checks the amount against configured thresholds. Approval rules can be tiered — for example a batch above €500 requiring one approver and a batch of a million requiring three — and approval can be given line by line or on the batch as a whole. Approvals can also be switched off entirely so batches are picked up from Oracle, formatted and sent to the bank without manual intervention.

What happens when the bank rejects a payment?

The bank returns an acknowledgement file over the same host-to-host or SFTP connection, which is picked up automatically and shown in the acknowledgement history along with the reason for each rejection — in the demonstrated case, an invalid IBAN. The rejection also appears in the supplier payment history, where the individual transaction can be voided; voiding is only permitted for transactions the bank actually rejected. The void is pushed to Oracle through a direct API so the status matches, and the transaction can then be included in a new payment batch.

Can non-XML invoices and non-PO invoices be handled?

PDF invoices can be collected by connecting an email account so they are fetched alongside e-invoices from portals. For coding, invoice lines carried in the XML support automatic PO matching, and for non-PO invoices accounting rules can be defined per supplier site that derive the correct code combination from XML header values, line values, or a combination of the two, allowing those invoices to be processed directly into Oracle as well.

Table of Contents

Get A Demo:

Simple solutions. Powerful results. Seamlessly integrated.

Get a PairSoft Demo