0:00 — Introduction and agenda — Peter opens the webinar on the Document Rejection Manager for Oracle, describing it as a module within the APRO imaging tool for rejecting incorrect invoices. He lays out the agenda: self-introduction, invoice exceptions and why a DRM matters, a demo, and Q&A. 0:50 — Presenter background — Peter introduces himself as an APRO employee of almost a decade, with a decade of experience in Oracle Financials Cloud and Oracle E-Business before that, now working on the sales side. 1:16 — Invoice exceptions and their cost — Research on the AP side is cited showing about 20% of incoming invoices are exceptions — a missing PO, not an invoice at all, an incorrect organization name, or other issues. Exceptions cost time and money and pull AP staff away from payables work. 2:06 — What the DRM does — The module can reject invoices automatically with a consistent supplier message, using editable templates that attach the invoice and state the problem. Rules can be grouped by business unit or supplier group, and the Oracle Financials Cloud integration allows checks against master data such as whether a PO number is valid, open, or finally closed. 3:56 — End-to-end rejection workflow — Invoices arrive by email, the Peppol network, SFTP, or a government portal; APRO scans the image or XML and evaluates active rules for PO data, organization name, invoice number, and duplicates. An automated rule triggers an email with the document embedded, a non-automated rule routes to the workbench for an AP user, and an invoice with no rule hit follows the normal path to the workbench or straight through to Oracle. 5:49 — Demo scenarios and email intake — Five test invoices are prepared covering an XML case, an incorrect organization name, an invoice number or duplicate issue, and one ordinary correct invoice. They are emailed to the APRO inbox so they can be fetched into the system. 6:43 — Logging in and the rejection history screen — Peter logs into Oracle Financials Cloud, opens the APRO sandbox and APRO imaging, and navigates to AP invoice automation where a scheduled process fetches invoices. With DRM active, a document rejection history screen appears alongside the normal invoice history screen, showing rejections over a period; fully automated rejections never reach the workbench. 8:43 — Import, recognition, and processing — The import is kicked off manually, and the invoices are picked up from email and put through XML and other recognition steps. The invoice history screen shows the five new invoices being processed, and the execution log shows the single picked-up email with its attachment, image, and XML counts. 10:53 — Results of the batch — After processing, three invoices are automatically rejected and one is moved to the rejected-invoices worklist for AP review rather than being sent back to the supplier. One invoice with no rule hit goes to the non-PO invoice flow for normal AP approval and transfer to Oracle. 12:00 — Reviewing rejection reasons and outbound emails — The document rejection history screen is searched by date to show each rejection and its reason, including an incorrect customer name and a duplicate invoice. Multiple rules can fire on one invoice, producing a single email listing all applied reasons, and the outbound email can be downloaded to see exactly what was sent. 13:50 — XML supplier and customer party name example — An XML invoice is examined where the accounting supplier and customer party names do not match the expected entity name, referring to a completely different organization, which is why it was rejected. The supplier inbox is then checked to show received rejection emails, including one invoice rejected for both no PO found and being a duplicate, with the original invoice attached. 15:28 — Manual rejection in the workbench — The workbench shows two new invoices — one correct and one in the rejected-invoices worklist because it was addressed to an individual rather than the company. The rejections tab shows the incorrect customer name reason; the AP user selects the applicable rule, edits the generated email, and sends it, while the correct invoice is saved, validated, and moved to Oracle. 17:18 — Overriding rejections and setup recap — An AP user can still send a rule-flagged invoice to Oracle if it is judged correct — for example a legitimately non-PO invoice rejected for a missing PO. The setup involves defining rules and groups by supplier group or business unit, after which the system scans, applies rules, and sends automated rejections, with the history screen distinguishing manual from automatic rejections. 19:33 — Q&A: name matching and disabling auto-send — Name-checking rules can be configured with multiple spelling scenarios, with and without commas, and can use the OCR spelling, to avoid rejecting invoices over naming variations. Automatic reject emails can be turned off per rule so the invoice moves to a separate workbench for AP review first. 20:46 — Q&A: PO exceptions, templates, and vendor exclusions — Invoices cannot go to Oracle without accounting, but a supplier that normally sends a PO can have an exception invoiced against an accounting string instead of matching a PO. Customers can create their own rules and email templates, and vendors can be excluded from rules — the PO rule checks Oracle's purchasing-site checkbox and skips non-PO suppliers. 22:43 — Q&A: history screen access, email lookup, and rule scope — The rejection history screen comes with the document rejection module and is available to users with APRO access. Recipient addresses are taken from the sending email, or from the XML or the supplier communication tab in Oracle master data when the sender is a no-reply address or the document arrived via Peppol. Rules can notify internal staff instead of suppliers, and can cover price issues and PO over-billing using Oracle data. 25:18 — Closing — Peter invites any unanswered questions by email, directly to him or to the known APRO address, and closes the webinar.

Home / Resources / Webinars

Demo: Automated Document Rejection Manager for Invoice Exceptions in Oracle

Key takeaways

Research cited in the webinar indicates roughly 20% of incoming AP invoices are exceptions, such as a missing PO, an incorrect organization name, or a document that is not an invoice at all.
The Document Rejection Manager (DRM) is a module inside the APRO imaging tool for Oracle Financials Cloud that applies configurable rules to incoming invoices and can reject them automatically.
Rejections generate a consistent email back to the supplier with the original invoice (PDF or XML) attached and the reason or reasons it was rejected; templates can be edited and created by the customer.
Rules can be set to reject automatically or to route the invoice to a separate rejected-invoices worklist for an AP user to review before any email is sent.
A new document rejection history screen sits alongside the invoice history screen and shows what was rejected, why, and lets you download the outbound email that was sent.
Because DRM integrates with Oracle master data, rules can check PO validity and status, duplicate invoices, supplier purchasing-site flags, price issues, and over-billing.
Invoices with no rule hit follow the normal flow to the workbench or straight through to Oracle, and an AP user can still push a rule-flagged invoice to Oracle if it is judged correct.

Overview

This webinar introduces the Document Rejection Manager (DRM), a module within the APRO imaging tool for Oracle Financials Cloud. It is presented by Peter, who has worked at APRO for almost a decade and has a decade of experience in Oracle Financials Cloud and Oracle E-Business, and who now works on the sales side. The stated purpose of DRM is to handle invoice exceptions — invoices that are incorrect, incomplete, duplicated, or not invoices at all — without requiring AP staff to process each one manually.

The problem framing comes from research on the AP side indicating that about 20% of incoming invoices are exceptions. Examples given include a missing PO number, an incorrect organization name, and documents that are not invoices. Each exception costs time, which is a financial cost, and pulls AP staff away from payables work onto problem handling. DRM addresses this by automatically rejecting invoices that hit a configured rule, sending a consistent, standardized message back to the supplier rather than ad-hoc or error-style messages.

The workflow described runs as follows: an invoice arrives through any supported source — email, the Peppol network, an SFTP drive, or a government portal — and APRO fetches and scans it, extracting data from the image or from an XML file. Active rules are then evaluated: PO information, organization name, presence of an invoice number, duplicate checks, and others. If a rule matches and is configured as automated, APRO builds an email from a template, embeds the original PDF or XML, and sends it back to the supplier. If the rule is not automated, the invoice moves to a workbench worklist where an AP user decides whether to reject it and which template to use. If no rule applies, the invoice continues through the normal path — to the workbench, or straight into Oracle Financials Cloud where straight-through processing is enabled. Because DRM is integrated with Oracle Financials Cloud, rule checks can be validated against Oracle master data, for example confirming whether a PO number exists, is still open, or is finally closed.

The live demo emails a batch of five invoices covering several scenarios — an XML case, an incorrect organization name, an invoice number or duplicate issue, and one ordinary correct invoice — into the APRO inbox and follows them through import, recognition, and rule evaluation in a sandbox environment. Of the batch, three invoices are rejected automatically and do not appear in the workbench at all, one is routed to a rejected-invoices worklist for manual review, and one non-PO invoice follows the normal approval flow toward Oracle. The document rejection history screen, which is added when DRM is active, is used to search rejections by date, see the reason for each rejection, and download the outbound email that was sent. One example shows an XML invoice rejected because the customer party name in the file referred to a completely different entity; another shows a supplier receiving a single email listing two reasons at once — no PO found and a duplicate — since multiple rules can fire on one invoice. The manual case is then worked in the workbench: the AP user opens the rejections tab, sees the incorrect customer name reason, chooses the applicable rule, edits the generated email, and sends it.

The Q&A covers configuration and cost questions. Name-matching rules can be set up with multiple spelling variants, with and without commas, and can also use the OCR spelling, so that naming differences do not cause unwanted rejections. Any rule can be switched from automatic rejection to routing into a separate workbench for AP review. Customers can create their own rules and email templates, which then appear automatically when the matching rule is selected in the workbench. Vendors can be excluded from rules — for the PO rule, APRO reads the purchasing-site checkbox in Oracle and skips the PO check for non-PO suppliers. Rules can also route notifications internally rather than to the supplier by excluding the company email account and entering an internal address in the supplier master data. Rejection rules can cover price issues, PO over-billing, and other PO problems, using data available through the Oracle integration. Recipient email addresses are resolved first from the sender of the incoming email; if that is a no-reply address, or if the document arrived as XML through Peppol rather than by email, APRO looks at the XML content or at the communication tab on the supplier site in Oracle master data. On cost, the presenter said that if the document rejection module is active, the history screen comes with it and is available to users who have access to APRO.

Chapters

0:00 — Introduction and agenda — Peter opens the webinar on the Document Rejection Manager for Oracle, describing it as a module within the APRO imaging tool for rejecting incorrect invoices. He lays out the agenda: self-introduction, invoice exceptions and why a DRM matters, a demo, and Q&A.
0:50 — Presenter background — Peter introduces himself as an APRO employee of almost a decade, with a decade of experience in Oracle Financials Cloud and Oracle E-Business before that, now working on the sales side.
1:16 — Invoice exceptions and their cost — Research on the AP side is cited showing about 20% of incoming invoices are exceptions — a missing PO, not an invoice at all, an incorrect organization name, or other issues. Exceptions cost time and money and pull AP staff away from payables work.
2:06 — What the DRM does — The module can reject invoices automatically with a consistent supplier message, using editable templates that attach the invoice and state the problem. Rules can be grouped by business unit or supplier group, and the Oracle Financials Cloud integration allows checks against master data such as whether a PO number is valid, open, or finally closed.
3:56 — End-to-end rejection workflow — Invoices arrive by email, the Peppol network, SFTP, or a government portal; APRO scans the image or XML and evaluates active rules for PO data, organization name, invoice number, and duplicates. An automated rule triggers an email with the document embedded, a non-automated rule routes to the workbench for an AP user, and an invoice with no rule hit follows the normal path to the workbench or straight through to Oracle.
5:49 — Demo scenarios and email intake — Five test invoices are prepared covering an XML case, an incorrect organization name, an invoice number or duplicate issue, and one ordinary correct invoice. They are emailed to the APRO inbox so they can be fetched into the system.
6:43 — Logging in and the rejection history screen — Peter logs into Oracle Financials Cloud, opens the APRO sandbox and APRO imaging, and navigates to AP invoice automation where a scheduled process fetches invoices. With DRM active, a document rejection history screen appears alongside the normal invoice history screen, showing rejections over a period; fully automated rejections never reach the workbench.
8:43 — Import, recognition, and processing — The import is kicked off manually, and the invoices are picked up from email and put through XML and other recognition steps. The invoice history screen shows the five new invoices being processed, and the execution log shows the single picked-up email with its attachment, image, and XML counts.
10:53 — Results of the batch — After processing, three invoices are automatically rejected and one is moved to the rejected-invoices worklist for AP review rather than being sent back to the supplier. One invoice with no rule hit goes to the non-PO invoice flow for normal AP approval and transfer to Oracle.
12:00 — Reviewing rejection reasons and outbound emails — The document rejection history screen is searched by date to show each rejection and its reason, including an incorrect customer name and a duplicate invoice. Multiple rules can fire on one invoice, producing a single email listing all applied reasons, and the outbound email can be downloaded to see exactly what was sent.
13:50 — XML supplier and customer party name example — An XML invoice is examined where the accounting supplier and customer party names do not match the expected entity name, referring to a completely different organization, which is why it was rejected. The supplier inbox is then checked to show received rejection emails, including one invoice rejected for both no PO found and being a duplicate, with the original invoice attached.
15:28 — Manual rejection in the workbench — The workbench shows two new invoices — one correct and one in the rejected-invoices worklist because it was addressed to an individual rather than the company. The rejections tab shows the incorrect customer name reason; the AP user selects the applicable rule, edits the generated email, and sends it, while the correct invoice is saved, validated, and moved to Oracle.
17:18 — Overriding rejections and setup recap — An AP user can still send a rule-flagged invoice to Oracle if it is judged correct — for example a legitimately non-PO invoice rejected for a missing PO. The setup involves defining rules and groups by supplier group or business unit, after which the system scans, applies rules, and sends automated rejections, with the history screen distinguishing manual from automatic rejections.
19:33 — Q&A: name matching and disabling auto-send — Name-checking rules can be configured with multiple spelling scenarios, with and without commas, and can use the OCR spelling, to avoid rejecting invoices over naming variations. Automatic reject emails can be turned off per rule so the invoice moves to a separate workbench for AP review first.
20:46 — Q&A: PO exceptions, templates, and vendor exclusions — Invoices cannot go to Oracle without accounting, but a supplier that normally sends a PO can have an exception invoiced against an accounting string instead of matching a PO. Customers can create their own rules and email templates, and vendors can be excluded from rules — the PO rule checks Oracle's purchasing-site checkbox and skips non-PO suppliers.
22:43 — Q&A: history screen access, email lookup, and rule scope — The rejection history screen comes with the document rejection module and is available to users with APRO access. Recipient addresses are taken from the sending email, or from the XML or the supplier communication tab in Oracle master data when the sender is a no-reply address or the document arrived via Peppol. Rules can notify internal staff instead of suppliers, and can cover price issues and PO over-billing using Oracle data.
25:18 — Closing — Peter invites any unanswered questions by email, directly to him or to the known APRO address, and closes the webinar.

Questions this webinar answers

What is the Document Rejection Manager and where does it run?

The Document Rejection Manager (DRM) is a module within the APRO imaging tool, integrated with Oracle Financials Cloud. It applies configurable rules to incoming supplier invoices and can reject invoices that fail those rules, either automatically or after review by an AP user.

What kinds of invoice exceptions can it detect?

Examples given include a missing or invalid PO number, a PO that is finally closed or still open, an incorrect organization or customer name, a missing invoice number, duplicate invoices, and documents that are not invoices at all. Price issues and PO over-billing can also be used as rejection rules, since the checks can use data available in Oracle through the integration.

What happens when an invoice is automatically rejected?

An email is generated from a template with the original document — the PDF or the XML — embedded, and it is sent back to the supplier along with the reason the invoice was rejected. Automatically rejected invoices are not placed in the AP workbench, so staff do not spend time on them. If several rules fire on the same invoice, the supplier receives one email listing all the applied reasons.

Can rejection be reviewed by a person before the email goes out?

Yes. A rule can be configured as non-automated, in which case the invoice is routed to a separate rejected-invoices worklist in the workbench instead of being sent back immediately. An AP user opens the invoice, sees the reason on the rejections tab, decides whether to reject it, selects the applicable rule and template, edits the email text if needed, and sends it.

Can an invoice that triggered a rule still be posted to Oracle?

Yes. If an AP user reviews a flagged invoice and judges it correct, it can still be saved, validated, and moved to Oracle. The example given was an invoice flagged for having no PO where a PO was genuinely not required because it was a non-PO invoice.

Can we create our own rules and email templates, and scope rules to specific groups?

Yes. Customers can create their own rules and their own email templates; when a rule is selected in the workbench, its associated template appears automatically. Rules can also be grouped — for example different rules per business unit or per supplier group.

How are name-matching rules kept from rejecting valid invoices over spelling differences?

Multiple spelling scenarios can be configured within APRO, including variants with and without commas, and the spelling produced by the OCR can also be used. The intent is to cover the possible variations so invoices are not rejected automatically because of a naming difference.

Can specific vendors be excluded from a rule?

Yes. For the PO rule, Oracle's purchasing-site checkbox on the supplier is read: if the checkbox is active, the PO check is applied; if it is not active — meaning a non-PO supplier — the rule is not applied.

How does the system know which email address to send a rejection to?

The first place checked is the sender address of the incoming email. If that is a no-reply address, the supplier's communication tab in Oracle master data is checked for active email accounts. For XML documents arriving through Peppol there is no sending email address, so the email account addressed inside the XML is used, or the supplier communication tab in master data is checked instead.

Is there an extra cost for the document rejection history screen?

The presenter said that if the document rejection module is active, the history screen comes with it and is available to users who have access to APRO.

Table of Contents

Get A Demo:

Simple solutions. Powerful results. Seamlessly integrated.

Get a PairSoft Demo