Demo: Outbound Global eInvoicing in Oracle Financials Cloud

• 0:06 — Introduction and agenda — The presenter opens the webinar on outbound e-invoicing and lays out the agenda: a self-introduction, an overview of global e-invoicing adoption, and a demo of the outbound e-invoicing solution.
• 0:36 — Presenter and company background — The presenter has worked at APRO for over ten years, moving from consulting to project management and now sales. APRO integrates out of the box with Oracle Cloud and Oracle E-Business Suite, is part of the US company PairSoft, and has teams in more than nine countries.
• 1:27 — Core e-invoicing features — Four core features are described: automation through XML that removes the need for OCR and maps data to Oracle open interface fields; standardization such as Peppol BIS 3.0; real-time reporting to governments for tax collection; and digital signatures that determine invoice validity, with Poland requiring a number on the invoice.
• 3:19 — Global adoption and business impact — Adoption spans Europe, India, Latin America, and voluntary use in the US. The practical impact is that a business must be able to send and receive XML invoices and automate processing of them, which is where APRO both collects invoices and posts them directly into Oracle.
• 4:08 — Supported countries and country models — APRO's supported-country list grows each month and the slide deck was to be shared afterwards. Country models differ: Italy routes invoices to the government first and then to the buyer, while a five-corner model sends the invoice to the government and directly to the buyer in parallel.
• 5:22 — The APRO platform and Oracle connection — The APRO platform handles both incoming and outgoing invoices across supported countries, connecting to Peppol and government platforms. It picks up transactions from Oracle, builds the XML and sometimes the PDF, and sends via email, government portal, Peppol, or an SFTP drive. No Oracle customizations are needed since all interfaces are built into the application.
• 6:44 — Oracle setup for outbound AR — Three attributes are created at the customer site level — send method, identifier, and XML format — plus an APRO status attribute on the transaction indicating sent, not picked up, or error. APRO also checks the bill flag; it does not create the PDF but picks up Oracle's PDF, embeds it in the XML, and sends it. All communication runs through APIs in both directions.
• 8:24 — Demo scenarios overview — The demo will cover two transactions: one sent to Shell over the Peppol network using a Peppol identifier and BIS 3.0 format, and a second that fails validation due to missing tags in the XML, which is then fixed and resent.
• 10:26 — Creating a transaction in Oracle — A newly created Oracle transaction is shown. APRO only picks up complete transactions and checks that the fields are correct: the APRO invoice status is empty, PDF and XML generation are both selected, and no attachment exists yet. After completion and sending, both the XML and PDF appear attached to the Oracle transaction.
• 10:56 — APRO runs and delivery confirmation — The APRO outbound main screen shows four areas, starting with the runs. Runs are scheduled — every five or ten minutes, hourly, or once a day — and show the send method, the customer identifier, and a finished flag confirming that the Peppol network reported delivery. A run from the previous day has no finished flag.
• 12:25 — Diagnosing and fixing a validation error — The failed-invoices workbench shows the transaction could not be generated because mandatory XML fields were missing: no tax amount and no invoice-including-tax field. In Oracle the PDF exists but the XML does not, so the presenter makes the transaction incomplete, adds the missing tax line (a zero value that must still be present), completes it, and revalidates the transaction in APRO for reprocessing.
• 14:53 — History, archiving, and wrap-up — The history screen lists completed invoices with both XML and PDF viewable in APRO and attached to the Oracle transaction, which also covers archiving; local in-country archiving is supported where required. The reprocessed invoice then shows as finished and sent, and the presenter closes by noting the outbound process is short because no customizations are needed.

What does the outbound e-invoicing process cover?

It covers the accounts receivable side — picking up completed transactions from Oracle Financials Cloud, generating the XML invoice (and optionally including the PDF), and sending it out through e-invoicing networks such as Peppol, government platforms, email, or to an SFTP drive for printing and mailing.

What needs to be configured in Oracle to make this work?

Three attributes are created at the customer site level: a send method, an identifier, and an XML format. On the transaction level, an APRO status attribute is added that indicates whether an invoice has been sent, has not been picked up, or has errored. The bill flag is also checked. No other customizations are needed — APRO is an out-of-the-box application with all interfaces already built in, and it communicates with Oracle through APIs in both directions.

Does the e-invoicing solution generate the PDF invoice?

No. Oracle typically already generates PDF invoices through a scheduled process. APRO picks up the existing PDF, places it inside the XML, and sends it over the chosen network. If a PDF is not yet attached, APRO can be set to produce both the PDF and the XML for that transaction.

Why do e-invoicing requirements differ by country?

Different countries use different transmission models. In Italy, invoices go first to the government, which then forwards them to the buyer. A five-corner model instead sends invoices in parallel — one copy to the government and one directly to the buyer. Validation rules also vary: in Poland a number must be present on the invoice before it counts as valid, while other Peppol countries send invoices without government involvement. A sending system has to be prepared for each country's specific model.

How often are invoices picked up and sent?

Sending is handled by a scheduled process that creates runs. The schedule is configurable — for example every five or ten minutes, once an hour, or once a day at a set time such as five or six o'clock.

How can you tell whether an invoice was actually delivered?

Each run has a finished flag. When it is checked, it means a delivery message was received back from the Peppol network confirming the invoice was correctly sent. If the flag is empty, the invoice was not sent and the reason has to be investigated.

What happens when an invoice fails validation?

The failed invoice appears in a workbench for failed invoices, where the reason is shown. In the demonstrated case, mandatory fields were missing from the XML — there was no tax amount and no invoice-including-tax field — and the transaction status in Oracle showed a validation error. The fix was to make the Oracle transaction incomplete, add the missing tax line (a zero value, but the line must exist), complete it again, and then revalidate the transaction so it is picked up and reprocessed on the next run.

Where are sent invoices stored?

Completed invoices are visible in the history screen, where both the XML file and the PDF file can be opened. The same two files are also attached behind the transaction in Oracle, which covers archiving. In countries where that is not sufficient, local archiving in the country where e-invoicing is required is also supported.