0:06 — What the demo will cover — The presenter outlines the two import scenarios: a hybrid PDF containing an embedded XML message that arrives by email, and Italian FatturaPA XML invoices. He explains that the invoice data must come from the XML while the PDF serves only as the image for the approval flow. 1:35 — Italian FatturaPA invoices — The second scenario uses two Italian suppliers sending FatturaPA invoices. These are XML files produced by the Italian government platform rather than standard UBL 2.0 or 2.1, and they arrive through a connected source rather than by email. 2:15 — Sending the email invoice — The hybrid PDF/XML invoice is emailed from AR to AP. The application connects directly to the mail account, polls inboxes and government connections continuously — checking every five to ten minutes — then picks up the message and moves it to a backup folder. 3:27 — Logging in and import overview — The presenter logs into the APRO cloud solution, selects an instance tied to a business unit, and opens AP invoice automation. The import overview lists the incoming sources — an email connection and an SFTP connection — and everything imported from each. The FatturaPA files are uploaded to the SFTP source. 5:38 — Workbench and straight-through processing — The workbench shows all imported invoices grouped by age, from under a day to invoices older than 8 to 14 days. Straight-through processing, which sends invoices from the mailbox directly to Oracle, can be activated per source, supplier site or business unit. 6:42 — Inspecting the hybrid invoice — Opening the hybrid invoice shows all header and line data already populated. The OCR text pane is empty, which indicates the data was read from XML rather than scanned. The amount is correct and the PO was found, with Oracle’s PO line information displayed alongside. 8:01 — PO matching and validation — The invoice is partially matched against a 10 million PO line by description, though other XML values such as price, quantity or item number can also drive matching. No manual data entry is needed; Save and Validate runs pre-checks and the validated invoice is pushed to Oracle. 9:07 — Work lists and exception queues — The two Italian invoices arrive and are routed to a separate work list. Queues separate exceptions such as invoices whose supplier site could not be recognised, which may indicate a new supplier or incorrect details on the invoice. Rejected invoices are also handled separately. 10:21 — Non-PO credit and generated PDF — A non-PO FatturaPA credit invoice is opened. Because many FatturaPA invoices contain no PDF, a placeholder PDF is generated from the XML so approvers have a readable document showing supplier and line data. Line recognition and coding are created automatically. 11:31 — Coding pre-checks before Oracle — A one-cent difference on a line is coded and saved. The validation history shows the invoice had not moved to Oracle because a line was missing coding — the pre-checks exist to keep invalid information out of Oracle. Once saved and validated, it is sent to Oracle via API. 12:24 — PO invoice with a freight line — A PO-matched FatturaPA invoice has five lines against four open PO lines; the extra five-euro line is freight not present on the PO. It is still matched because receiving may be needed even on zero-amount lines. The only hold shown is that straight-through processing is not enabled for this supplier. 13:46 — Invoice history and reporting — The invoice history screen filters processed invoices by period, shows status including rejection reasons, and can be exported, run as reports, detached for readability, and filtered to PO invoices only. It also shows whether an invoice has reached Oracle Payables and its Oracle status. 15:02 — Verifying the results in Oracle — In Oracle Payables the imported invoices appear in “needs revalidation” status. Attachments include both the XML original and the PDF. The FatturaPA credit is booked as a credit memo automatically, with the generated PDF attached for the Oracle workflow, and the differing XML structures are both mapped correctly. 18:33 — Q&A: EBS support and XML validity — The solution is available for Oracle E-Business Suite as well as Oracle Financials Cloud / Fusion Financials. On recording XML validity for audit, the answer given is that the Peppol network and government platforms reject non-compliant invoices at the sending end, so invalid electronic invoices are not received. 20:59 — Q&A: comparison with Oracle IDR — Oracle’s Intelligent Document Recognition processes PDF invoices but does not process electronic invoices. Differences are described in terms of volumes, automation, and handling multiple countries and business units. Oracle does not connect to government platforms or the Peppol network and directs customers to third-party e-invoicing partners. 22:29 — Q&A: generated PDFs and acceptance — A PDF is generated from XML data only when the vendor’s XML contains no PDF. Governments accept the XML itself as the original invoice, so the generated document is an image for visibility rather than the invoice. 23:39 — Q&A: implementation timelines and close — E-invoicing-only implementation is put at five to ten working days, faster for existing customers, and up to about fifteen days for a full implementation depending on volumes and PO/non-PO mix. One new customer was processing invoices in a system integration test within four hours of setup starting.

Home / Resources / Webinars

Demo: eInvoicing in Oracle Financials to comply with global mandates on PDF invoices

Key takeaways

The demo covers importing two kinds of electronic invoices into Oracle: a ZUGFeRD-style PDF with embedded XML arriving by email, and Italian FatturaPA XML invoices arriving over an SFTP connection from a government-linked source.
For hybrid PDF/XML invoices, the invoice data is taken from the embedded XML while the PDF is kept only as the image used for the approval workflow, and both files end up as attachments on the Oracle invoice.
The APRO application polls connected mailboxes and SFTP/government connections continuously (checks roughly every five to ten minutes), moves picked-up email to a backup folder, and imports the invoice.
When an XML invoice contains no PDF image, the application generates a placeholder PDF from the XML data so approvers have something readable; the XML remains the legal original invoice.
Invoices are validated in APRO before being pushed to Oracle via API — PO matching, line coding and pre-checks happen first, so incomplete invoices are held back rather than landing in Oracle invalid.
Straight-through processing can be enabled per source, supplier site or business unit so invoices bypass manual review entirely and go straight to Oracle.
The solution is available for both Oracle E-Business Suite and Oracle Fusion/Financials Cloud, and e-invoicing implementation is quoted at roughly five to ten working days, up to about fifteen for a full new implementation.

Overview

This webinar is a live product demonstration of an e-invoicing and AP automation application, referred to as APRO, running alongside Oracle Financials Cloud. The stated problem is that global mandates are shifting invoices away from PDFs toward structured XML formats, and that raw XML is not something an AP clerk or an approver can read or process directly. The demo shows how incoming electronic invoices in different formats are ingested, interpreted, checked and then pushed into Oracle Payables as normal invoices.

Two scenarios are demonstrated. The first is a hybrid document — a file that arrives by email looking like an ordinary PDF but containing an embedded XML message. The presenter explains that the correct handling is to extract the invoice data from the XML, because that is the original invoice, and to use the PDF only as the visual image for the approval flow. The second scenario uses Italian FatturaPA invoices from two suppliers, delivered as XML from the government platform rather than as standard UBL, and arriving through an SFTP connection rather than email. The presenter notes that the application does not care which XML format it receives; it maps the data from either structure into the correct Oracle fields.

The demo walks through the application’s own interface, which is described as deliberately similar in look to Oracle’s. An import overview shows all incoming sources — an email connection and an SFTP connection — polled automatically every few minutes. A workbench lists imported invoices by age. Opening an invoice shows all header and line data already populated from the XML; the presenter points out that the OCR text pane is empty, which is how he can tell the data came from XML rather than from scanning a PDF. One invoice is automatically partially matched against an open PO line by description, then saved and validated, which runs pre-checks before pushing it to Oracle. Another invoice is held back because a line was missing coding — the pre-checks are presented as the mechanism that keeps invalid data out of Oracle. A third invoice matches a PO but has an extra freight line with no corresponding PO line, and is still matched so receiving can be handled.

Several operational features are shown: work lists or queues that separate exceptions such as unrecognised supplier sites, rejection of invoices with a mandatory rejection reason, an invoice history screen filterable by period and by PO/non-PO with exportable data and Oracle-side status, and straight-through processing configurable per source, supplier site or business unit. The demo ends inside Oracle Payables, where the imported invoices appear in “needs revalidation” status with both the XML and the PDF present as attachments, including a credit memo that was classified automatically.

The closing Q&A covers four points. The solution exists for Oracle E-Business Suite as well as Oracle Fusion Financials Cloud. On XML validity for audit purposes, the answer given is that Peppol and government platforms reject non-compliant invoices at the sending end, so invalid electronic invoices are not received in the first place. On how this differs from Oracle’s built-in Intelligent Document Recognition, the answer is that IDR handles PDF invoices only and does not process electronic invoices, and Oracle directs customers to find a third-party e-invoicing partner because Oracle does not connect to government platforms or the Peppol network itself. On generated PDFs, the presenter clarifies that a PDF is only created when the vendor’s XML contains no image, and that governments accept the XML as the original invoice, so the generated PDF is purely for visibility. On timelines, an e-invoicing-only implementation is put at five to ten working days, a full implementation for a customer with no existing products at up to about fifteen days, with one example of a new customer processing invoices in a system integration test within four hours of setup starting.

Chapters

0:06 — What the demo will cover — The presenter outlines the two import scenarios: a hybrid PDF containing an embedded XML message that arrives by email, and Italian FatturaPA XML invoices. He explains that the invoice data must come from the XML while the PDF serves only as the image for the approval flow.
1:35 — Italian FatturaPA invoices — The second scenario uses two Italian suppliers sending FatturaPA invoices. These are XML files produced by the Italian government platform rather than standard UBL 2.0 or 2.1, and they arrive through a connected source rather than by email.
2:15 — Sending the email invoice — The hybrid PDF/XML invoice is emailed from AR to AP. The application connects directly to the mail account, polls inboxes and government connections continuously — checking every five to ten minutes — then picks up the message and moves it to a backup folder.
3:27 — Logging in and import overview — The presenter logs into the APRO cloud solution, selects an instance tied to a business unit, and opens AP invoice automation. The import overview lists the incoming sources — an email connection and an SFTP connection — and everything imported from each. The FatturaPA files are uploaded to the SFTP source.
5:38 — Workbench and straight-through processing — The workbench shows all imported invoices grouped by age, from under a day to invoices older than 8 to 14 days. Straight-through processing, which sends invoices from the mailbox directly to Oracle, can be activated per source, supplier site or business unit.
6:42 — Inspecting the hybrid invoice — Opening the hybrid invoice shows all header and line data already populated. The OCR text pane is empty, which indicates the data was read from XML rather than scanned. The amount is correct and the PO was found, with Oracle’s PO line information displayed alongside.
8:01 — PO matching and validation — The invoice is partially matched against a 10 million PO line by description, though other XML values such as price, quantity or item number can also drive matching. No manual data entry is needed; Save and Validate runs pre-checks and the validated invoice is pushed to Oracle.
9:07 — Work lists and exception queues — The two Italian invoices arrive and are routed to a separate work list. Queues separate exceptions such as invoices whose supplier site could not be recognised, which may indicate a new supplier or incorrect details on the invoice. Rejected invoices are also handled separately.
10:21 — Non-PO credit and generated PDF — A non-PO FatturaPA credit invoice is opened. Because many FatturaPA invoices contain no PDF, a placeholder PDF is generated from the XML so approvers have a readable document showing supplier and line data. Line recognition and coding are created automatically.
11:31 — Coding pre-checks before Oracle — A one-cent difference on a line is coded and saved. The validation history shows the invoice had not moved to Oracle because a line was missing coding — the pre-checks exist to keep invalid information out of Oracle. Once saved and validated, it is sent to Oracle via API.
12:24 — PO invoice with a freight line — A PO-matched FatturaPA invoice has five lines against four open PO lines; the extra five-euro line is freight not present on the PO. It is still matched because receiving may be needed even on zero-amount lines. The only hold shown is that straight-through processing is not enabled for this supplier.
13:46 — Invoice history and reporting — The invoice history screen filters processed invoices by period, shows status including rejection reasons, and can be exported, run as reports, detached for readability, and filtered to PO invoices only. It also shows whether an invoice has reached Oracle Payables and its Oracle status.
15:02 — Verifying the results in Oracle — In Oracle Payables the imported invoices appear in “needs revalidation” status. Attachments include both the XML original and the PDF. The FatturaPA credit is booked as a credit memo automatically, with the generated PDF attached for the Oracle workflow, and the differing XML structures are both mapped correctly.
18:33 — Q&A: EBS support and XML validity — The solution is available for Oracle E-Business Suite as well as Oracle Financials Cloud / Fusion Financials. On recording XML validity for audit, the answer given is that the Peppol network and government platforms reject non-compliant invoices at the sending end, so invalid electronic invoices are not received.
20:59 — Q&A: comparison with Oracle IDR — Oracle’s Intelligent Document Recognition processes PDF invoices but does not process electronic invoices. Differences are described in terms of volumes, automation, and handling multiple countries and business units. Oracle does not connect to government platforms or the Peppol network and directs customers to third-party e-invoicing partners.
22:29 — Q&A: generated PDFs and acceptance — A PDF is generated from XML data only when the vendor’s XML contains no PDF. Governments accept the XML itself as the original invoice, so the generated document is an image for visibility rather than the invoice.
23:39 — Q&A: implementation timelines and close — E-invoicing-only implementation is put at five to ten working days, faster for existing customers, and up to about fifteen days for a full implementation depending on volumes and PO/non-PO mix. One new customer was processing invoices in a system integration test within four hours of setup starting.

Questions this webinar answers

How is a PDF invoice with embedded XML handled?

The invoice data is extracted from the embedded XML, because the XML is the original invoice. The PDF is retained and used only as the visual image for the approval flow, so the invoice can be reviewed and approved for payment. Once the invoice reaches Oracle, both the XML and the PDF are visible behind the attachment button on the invoice.

Does the application support XML formats other than UBL?

Yes. The demonstration covered a hybrid PDF-with-embedded-XML document and Italian FatturaPA invoices, which are XML files created by the Italian government platform rather than standard UBL 2.0 or 2.1. Peppol BIS 3.0 and the German XRechnung format were also mentioned as supported inputs. The format was described as not mattering to the application, which maps the data from each structure into the correct Oracle fields.

What happens when an XML invoice contains no PDF image?

A placeholder PDF is generated from the XML data, showing the supplier information and line details in the correct fields, so that an approver has something readable instead of having to open an XML file. Approvers can tell the document was system-generated. The XML remains the legal original invoice; the generated PDF exists only for visibility, and governments accept the XML as the original.

How do invoices get from the supplier into the system?

Two sources were shown: a direct connection to a mail account, and an SFTP connection that can be a government portal or another system. Both are polled automatically around the clock, with new invoices checked for roughly every five to ten minutes. When an email invoice is picked up it is imported and the original message is moved to a backup folder.

Can invoices go straight into Oracle without manual review?

Yes. This is called straight-through processing and can be activated per source, per supplier site, or per business unit. When it is enabled for a supplier, the invoice is not shown for review in the AP application and goes directly to Oracle. It can be left off initially so users can first confirm that data extraction from the XML and PO matching are correct.

What checks run before an invoice is sent to Oracle?

A Save and Validate step runs pre-checks covering whether all required invoice data is present and whether the invoice is correctly processed, and issues warnings if not. In the demonstration one invoice was held back because a line was missing coding, and only moved to Oracle after the coding was completed. The stated purpose is to prevent invalid information from reaching Oracle. Validated invoices are sent to Oracle over an API on a continuous connection.

How does this differ from Oracle’s built-in Intelligent Document Recognition?

IDR processes PDF invoices, which the APRO application also does. The differences described are in volumes, degree of automation, and handling of multiple countries and multiple business units, including business unit recognition. More significantly, IDR does not process electronic invoices at all, and Oracle does not connect to government platforms or the Peppol network, so Oracle directs customers to find a third-party e-invoicing partner in the marketplace.

Is the solution available for Oracle E-Business Suite as well as Cloud?

Yes. There is a version compatible with Oracle E-Business Suite that processes invoices into Oracle EBS, and a version for Oracle Financials Cloud that processes invoices into Oracle Payables in Oracle Fusion Financials.

How long does an e-invoicing implementation take?

An e-invoicing-only implementation was estimated at five to ten working days, varying with the number of countries involved and whether the target is Oracle E-Business Suite or Cloud, and testing must be completed on a test environment before moving to production. Organisations already using the vendor’s imaging product on Oracle Financials can expect it to be faster; a full implementation for a customer with no existing products was put at up to around fifteen days, depending on volumes and whether invoices are PO or non-PO. In one case a new customer with good advance preparation was processing invoices in a system integration test within four hours of setup beginning.

Table of Contents

Get A Demo:

Simple solutions. Powerful results. Seamlessly integrated.

Get a PairSoft Demo