Introduction

Matching invoices and purchase order details is a critical validation step prior to payment. When things go wrong and errors must be resolved, requiring the cooperation of two, three or four teams, even an organization with the best intentions can find things go awry. This is a common pain point where those teams will compare their ability to communicate and resolve issues in Oracle, with their legacy system. If done well, they all appreciate and advocate for how Oracle Fusion has made a positive impact in their day-to-day work. If not managed effectively, it can cause widespread disruption and reduce the overall implementation project's effectiveness.

Match Exceptions involve several teams, and the challenges are not just technical, but highly focused on business processes and business culture. Existing documentation may help with technical steps, but this is a first-of-its-kind look across the four involved teams and holistic, practical solutions, guided by years of hands-on experience helping resolve and build processes for client success.

First, let's consider that this is just a small piece of the overall Supply Chain or P2P structure. This is diagram I use with my clients and teams at Huron Consulting Group, to help them visualize how various modules and tasks interact. It is not exhaustive, but it is designed to show the significant setup steps and downstream functions that are impacted at each phase. Most of the match exception work mentioned in this article exists in the blue boxes, between the

• Buyers, Procurement Agents and Catalog Managers
• Payable Clerks
• Receiving Docks and Requesters performing Desktop Receipts
• Inspection teams, like Quality or Clinical Engineering

Figure 1 High Level flowchart of Procure to Pay tasks and modules in Oracle Fusion

What is Invoice Matching?

Several of those teams may not give much consideration to the invoice phase and what is matched on the invoice, or even know what matching is. When we have placed an order with a supplier, they will eventually send an invoice. While invoices may have their own approval workflow, matching them to a purchase order has several functions

• Avoids errors, like a supplier entering the wrong price, item or quantity
• Avoids fraud, like a supplier invoicing without providing goods or services or mimicking a real supplier to trick us into paying the wrong entity
• Confirms the PO price and costing information, allowing us to clear encumbrances and charge the right amounts to the right accounts, including variance accounts.

To be clear, Matching is part of the Validation process, which occurs before the Approval process. It would not make sense to bother an executive with an approval, only to later realize that the invoice had an error. This article is about Match Exceptions, but those are not the only type of Exception. Validation includes other Exceptions, like whether the sum of the line values matches the total invoice value.

Match Levels

When we are matching to a PO, there are 3 main types of levels of matching, based on the order type, and set on the order line.

• 2 Way: Matching the PO and the Invoice. Commonly used for service orders where there is nothing that a receiving dock can enter as the receipt.
• 3 Way: Matching the PO, the Invoice, and the Receipt. Commonly used for goods, whether inventoried or expensed, where the receiving dock would enter the transaction when the pallet or cases arrive.
• 4 Way: Matching the PO, the Invoice, the Receipt, and the Inspection. Commonly used for goods that need to pass a strict quality inspection, or clinical engineering type items that require setup to confirm they work as expected.

Every order is unique, and every client may pick unique ways to describe them. In Setup and Maintenance, you create Line Types and select whether they are 2-, 3- or 4- way match. For example, this client may call this line type Goods, but another client could call it Stuff. Additionally, you could have multiple line types that have the same type of configuration but allow you additional granularity on reporting. For example, Medical Goods compared to Housekeeping Goods. Keep in mind that on a Smart Form, you default to a single line type. Smart Forms allow you to place non catalog, or special, requisition lines without requiring Requesters to know how to fill out fields like Line Type

Figure 2 Setup and Maintenance task Manage Purchasing Line Types demonstrating how match levels may be set on a line type

You will set a default Line Type in the Requisitioning Business Unit Functions page, enter a Line Type for a Smart Form, or set the Line Type on the BPA. Lastly, Buyers may override and separately control whether the line is 3-way matching on the PO level regardless of those other settings. However, unlike values like Payment Terms, where the Invoice overrides the PO, the Supplier cannot change the Match Type, as this is an internal control for an organization.

What Details are Matched?

Broadly, the system is checking whether the invoice quantity and price are within acceptable limits for both percentages and total amount. Clients have control over which of those checks are done, and what is acceptable for their industry, and these limits may also be set for each Supplier Site uniquely. However, each check is unique. If an invoice line breaks 2 tolerances, it will get 2 holds, each of which may be resolved and released independent of the other. Conversely, this also means that we cannot combine the limits in a logical rule, they always stand alone. The invoice cannot be paid until all holds are removed. This is a key difference for Oracle Cloud compared to some other systems, which allow a more complex control where rules may be evaluated with complex and/or logical statements, at the end of which only a single hold is placed, but which describes how the limits are broken.

What is a Hold and Release?

This article is specifically about match holds, but those are not the only type. There are many other validations holds that could be placed, such as if the line amounts sum does not match the invoice total. Those holds are only visible to AP and not the buyers, but all holds must be released before an invoice may be Validated, then Approved, then Paid.

Holds and Releases are managed in the Manage Invoice Holds and Releases page in Setup and Maintenance. The system holds we are discussing today, may not be renamed, but you may change Descriptions. You may create additional holds, but the holds you make would be applied,

• Manually in the Manage Invoice screen in UI
• Through a REST API, including Oracle tools like Visual Builder Add in for Excel, Postman, or an integration
• Through SOAP, such as More4Apps Finance Module tools in Excel, or an integration

However, Oracle cannot apply system logic to apply or release your own custom holds.

A Tolerance is the threshold for a certain parameter which will apply to a system Hold, which has both a Code and a Name. Separate tolerances exist for Amount and Quantity based orders, even when the concept of the tolerance or hold is similar or identical, and the Hold Codes and Names do not always line up very nicely with the Tolerance

Great care should be taken to updating Hold Names and Descriptions, so they are more easily understood by users, and making sure everyone feels comfortable during testing that the system always —always! — applies the tolerances correctly. One caveat to keep in mind during both testing and in production, is that invoice validation is not instant, and sometimes hold conditions have aligned in a way that will result in the hold being released; but it stays applied until the invoice is revalidated.

Finally, holds have some important properties for Matching: Manual Release and Holds Resolution Routing.

Manual Release

Manual Release is off by default on system holds. That means the way to release a match exception hold is to fix the issue. For example, if your price tolerance is 10%, and you have a PO for 1 unit at $100, and an invoice that says the price should be $125, the way to release the hold is to either change the PO price to $125 (or within 10% of it), or adjust the invoice down.

However, you could choose to allow manual release for system holds, which would allow AP (not buyers or requesters) to remove the hold. To accomplish this, you also need to define a Match Release Code which would be listed when performing the manual release. In order words, you can use this like a reason code, so an AP user would have the ability to indicate why the release is being done. But there is no security for selective use code by code; anyone with the privileges to release holds can release any hold with a corresponding hold reason.

Keep in mind that fixing the root cause of price holds will ensure that costs go to the correct charge account. If you manually release the hold, they will go to the Variance Account. If you allow manual hold release, consider ensuring that your variance account is the same as your charge account, which you can do via a Transaction Account Definition rule.

Holds Resolution Routing

Holds Resolution Routing is also off by default. This allows you to use BPM style notifications to send alerts about holds to interested parties, but it is far from a perfect solution. For starters, it requires that the match hold be made manually releasable. This has the impact of allowing you to control which holds would send a notification. It only has a single stage for routing and has limited routing options. One to consider is the ability to group hold types together, the possibilities of which are included in figure 4 below. For example, ordered percentage and maximum ordered may be sent in a single notification even if there are multiple holds, but you cannot combine a received percentage and ordered percent hold in the same notification.

The information included in the notification is customizable via BI Publisher, and includes the overbilled quantity, overbilled amount, price variance and quantity missing receipt, but it only includes this for the invoice that has the hold, and in later portions of this whitepaper we will discuss how this is an extremely fatal flaw; treating the hold as the information when in fact, it is merely data.

However, if you do elect to override price holds instead of fixing the purchasing document, then you should consider how the appropriate routing rules here could give you an easier way to notify buyers and involve them in the override. The notification task in BPM is the aptly named FinApHoldApproval.

An advantage of fixing the root cause, like for price, is that an item you buy frequently will continue to generate holds which must be removed, until you fix the BPA. If you fix the BPA, then future orders have the right price and will not generate the hold, which is better than simply overriding daily. That said, there is a time and place for both: Use holds resolution routing and fix the BPA, instead of fixing the BPA and updating the price. Another consideration is that the difference in price is charged to the Variance Account, which can be set up to be the same or different than the Charge Account.

Figure 3 Example of how variances are displayed on the Hold Resolution Routing notification sent if enabled on a hold

Figure 4 Chart of grouping actions possible for Hold Resolution Routing

Receipt Confirmation Notification

You should also consider the Receipt Confirmation notification process, another BPM notification process under the task ConfirmReceiptRequestForAction. This process generates a notification that is sent to the Requester on the requisition (or to the Buyer if there is no Requester) when there is an invoice on hold for Qty Rec hold and there is also an open quantity on the PO for receipt. This notification includes details on the invoiced quantity and the remaining PO quantity. There is an option to receive the full PO, only receive up to the invoiced amount, or to indicate that you did not receive the item.

You can configure the application to notify the buyer or close the notification upon non-receiving. This process is controlled by an ESS Job and usually would be run periodically. One issue with this process is that EDI invoices usually arrive faster than the physical items, and there is no way to delay the notification for a certain period after the ETA or after the invoice is placed on hold, beyond delaying the entire ESS job. There is an option to instead, trigger the notification upon ETA instead of against invoice hold status, but this requires that you responsibly manage your ETAs, otherwise you are trading one source of unwanted emails for another.

The notification is not editable via BI Publisher, but you can remove buttons like Receive In Full by controlling the BPM Notification settings.

Figure 5 Example email demonstrating the information included in Receipt Confirmation Notifications and the possible actions

Receipt Matching vs. Invoice Approval

For expensed goods purchases, there is a general desire to ensure items were delivered before the invoice is paid. One way to do this is via a Receipt. Inventoried items always require a receipt, so they may be tracked in inventory, and organizations which maintain inventory usually have a centralized receiving system and prefer to process receipts for expensed items as well. However, even in these organizations, a large volume of items skip the receiving dock, or arrive without clear documentation to allow for the receipt. This ends up requiring Desktop Receiving, where the requesters use My Receipts task or Receipt Confirmation email to confirm receipt.

An alternative option is to use Invoice Approval routing to send the invoice to the Requester, with the logic that Requesters do not approve the Invoice if they have not received the item. If an organization does not have a central receiving dock and does not desire to add the complications of receiving transactions on top of invoice approvals, this is a great method for accomplishing the principle of validation prior to payment, without receipts. Other match exceptions for 2 - way tolerances would still apply.

Invoice Matching Errors

A common question is “why would an invoice be matched incorrectly?” The main three reasons are wrong invoice information for PO or PO Line, kit parts listed out on the invoice even at $0, and manual AP mistakes.

When Oracle is matching, it prioritizes the invoice data for PO Line over other information on the invoice like supplier item. Suppliers may not take care and put the wrong PO Line on the invoice.

In other cases, there may be an item where the supplier intakes the order as a single item, like a Swab Kit, but where they store the items as both a specimen cup and a cotton swab. On their side, they may be picking those and combining them at the time of shipping, and for tracking purposes, listing those out on a packing list as components, and therefore, including them both on the invoice. Imagine an invoice that lists multiple items for the same PO Line like this:

PO 123 Line 1: Swab Kit--Supplier Item SK1–Qty 1 $199

PO 123 Line 1: Specimen Cup—Supplier Item SC1–Qty 1 $0

PO 123 Line 1: Cotton Swab – Supplier Item CS1–Qty 1 $0

Oracle will match all 3 lines to PO Line 1, summing to a quantity of 3. Even though the PO and invoice match at $199, the quantity no longer matches, and this goes on Qty Ord hold, and Qty Rec hold. If you use Hold Resolution Routing, this will go to the buyer. If you use the new Redwood resolution feature, this shows up on their dashboard to increase the PO Quantity by 2. If you use Receipt Confirmation notification, it sends a request for the Requester to confirm receipt of 3 Each.

This is not fixable or trainable via IDR, but there is a partial solution with EDI invoices: simply removing the PO Line value will force Oracle to match based on the supplier item number. For the wrong PO Line invoices, this may be enough to completely fix the issue. For the kit issue, it will result in the other 2 lines being unmatched and requiring AP review via Correct Import Errors, but this can still reduce the volume of bad hold information going out to teams to resolve. The AP team can update UOM on the invoice lines to match the UOM specified on the PO, like Kit instead of multiple Eaches. Vendors with this issue are not eligible for IDR, they should be pushed to EDI or manually entered.

To implement this style of fix,

• Find the Collaboration Message Definition used by searching for an invoice in Manage Collaboration Messaging History
• Export the Transformation Package from Collaboration Message Definitions
• Edit in Notepad++ and reimport

Figure 6 Original code for sending PO Line Number

Figure 7 Updated code removing PO Line Number from EDI Messages

Tolerances

Now let's review tolerances and how they are applied. We will focus on the more commonly used tolerances, which often exist in related pairs, where one value is a gross amount, and the other is a percentage. We will also provide examples to show how the calculations are performed. Pay close attention to the difference between Tolerance Name, Hold Name and Hold Code. It is extremely easy to be confused between the gross amount and percentage calculation holds due to mismatches between each field name.

Broadly, there are 2 types of tolerances, Quantity or Amount. This is because a Quantity based order will have a unit price and a quantity, for example $300 per hour and 10 hours of consulting services. Whereas an Amount based order will have an amount, like $3000 for consulting services. The hold concepts are often similar between the two, even if one has a math problem (unit price * quantity) and the other is just amount, so we will explain the similar holds together

You will set the default matching tolerance in Manage Invoice Options, and you can set a supplier site specific tolerance in the Supplier Site Invoicing Controls section. Each tolerance is enabled or disabled by the flag on the row, and a key feature to note is that setting a tolerance to 0 and checking the flag means that the rule is checked and the allowable variance is 0. If you want the rule to be checked and the tolerable variance very large, you would enter a large number like 99999. If you uncheck the flag, then regardless of the value entered, the rule is simply not checked. Great care should be taken with this flag, because unchecking and running Validate Payables Invoices job will release existing holds on all invoices; but checking this and running Validate Payables Invoices job will not apply holds to all invoices. If you unselect this flag by mistake and need to re - apply holds, you have to validate each open invoice manually, or using a rest api. The ESS Job does not correctly re-validate and apply new holds to invoices that had a hold released already.

Figure 8 Setup and Maintenance task Manage Invoice Options (Payables) showing where to enter the default Quantity and Amount tolerances

Figure 9 Supplier Management showing how Sites may be set with a unique Quantity and Amount tolerance different from the overall value

This tolerance checks the percentage of invoiced quantity compared to the ordered quantity. For example, an order for 100 desks but an invoice for 110 desks would be a 10% discrepancy. If the limit is 0, then no excess is allowed, not even a single unit extra.

This tolerance checks the count of units invoiced vs. the ordered quantity. For example, an order for 100 desks but an invoice for 110 desks would be a 10-unit discrepancy. If the limit is 0, then no excess is allowed, not even a single unit extra.

Remember that each rule is evaluated by itself. This means that the Ordered Percentage and Ordered Quantity rules are regardless of price or receipt quantities.

Consider a situation where a vendor for labels has produced 100 extra units on an order for 5000 labels. The price was $0.10 per label, but the client does not accept a bill higher than their original quote. The supplier does not want to throw the labels in the trash, and they must send accurate packing lists, so they list the 5,100 labels. Their invoice is automatically generated as the labels are shipped, for the 5,100 quantity. If the client has a strict Ordered Percentage or Maximum Ordered Quantity tolerance, this line may go on hold, even though they cost nothing!

This also separate from the Receipt tolerance on the PO: even if the units were received, these Quantity rules will not allow any invoice over the limit. Conversely, if your receipt tolerances disallow receipts over a certain limit, having a Quantity rule in invoice match exceptions greater than the Receipt tolerance, will not allow the extra receipt

Please keep in mind how this relates to over receipt limits, which are expressed only in percentages, not in units. If you allow a receipt for a greater limit than your invoices, then you could be missing an opportunity to identify the problem earlier. However, if you have a high volume receiving dock with no room to pause for supplier issues like this, it may still make sense to receive extra units and resolve the issue with the supplier, later.

This tolerance compares the received quantity to the invoiced quantity and calculates the over receipt percentage. For example, if you have ordered 100 desks, but only have received 80, while the supplier has already sent the invoice for the full 100 desks, we can calculate the percentage as invoiced – received / received, or 100 – 80 / 80, or 20/80, which is 25%. If your tolerance was 15%, then this invoice would go on QTY REC hold.

This tolerance compares the received quantity to the invoiced quantity and calculates the gross quantity not received compared to the invoice. For example, if you have ordered 100 desks, but only have received 80, while the supplier has already sent the invoice for the full 100 desks, we can calculate the percentage as invoiced – received, or 100 - 80, or 20. If your tolerance is 10, then this invoice will go on MAX QTY REC hold.

This tolerance compares the invoiced unit price to the PO unit price and calculates the percentage differences compared to the PO unit price, or invoice unit price – PO unit price / PO unit price. For example, if your invoiced unit price is $13.80 each, and your PO price is $12.25 each, this is a difference of $1.55, or 1.55/12.25 or 12.65%. If you allow only a maximum of 8% difference, this invoice will go on PRICE hold. Note that percentages are entered as a number, so 8% is entered as 8.

This tolerance is a running total on the line for the extended impact of price differences. The key reason to consider this as a running total is that price differences are immediately noticed regardless of quantity. Schedule Amount is a gross dollar amount and helps you to quantify the materiality of price percentage differences. For example, a difference of $0.0005 on a $2 item is well under 1%; but if you have ordered 1,000,000 of this item, it adds up to $500.

But this difference is not felt immediately. If your supplier splits this million - unit shipment into 200 deliveries, the over payment on the first delivery and invoice would only be $2.5. With the next delivery, you have the same difference of $2.50, but our running total is now $5. If your Maximum Schedule Amount is $25, then on the 11th delivery you will cross the threshold and all future invoices for this item will go on hold for Max Ship Amt. This is one of the most confusing topics for AP and Buyers to understand. Adding to the confusion is the combination of “Schedule” and “Ship,” inconsistent and confusing to teams who are not used to the concept of schedules

Other Holds

Conversion Rate Amount, Consumed Percentage and Maximum Consumed Amount are not as widely used. Conversion Rate Amount is used when you have multiple currencies, and you want to control the price difference across currencies. Consumption amounts are used for consignment agreements when the supplier is invoicing you for a different percentage or amount than you have reported using in your consumption reports.

User Defined Holds

In 24C , Oracle released a new feature called User Defined Holds. This sounds very promising, but it does not work for match type holds, nor for line and distribution variance holds. It allows you to create new hold types using an Excel spreadsheet which has a list of input criteria, for example, Supplier type, Source, BU Name, Amount and DFF values. An example is shared below.

Figure 12 Demonstration of creating User Defined Holds, which are not applicable to Match Holds

Figure 13 Setup and Maintenance task Manage Invoice Holds and Releases

Figure 14 Example of setting a hold or release and the setups to make it manually releasable and whether to use hold routing

Hold Visibility

Payables Hold Review

On the AP Dashboard, they can see an infotile showing the count of holds, grouped by type of hold. The holds we are talking about are Matching Holds, and because they are related to the purchase order, they are grouped under the Purchasing section.

Figure 15 Payables Dashboard view showing where they see Match Hold counts

Remember that there are many holds that are AP specific, like when the sum of line amounts does not match with the total of the invoice. AP needs to monitor and react to all holds, but this article is focused on match exception holds. This infotile gives the ability to filter by 7, 15, 30 or all days based on age of the hold. As usual, you can “query by example” or filter on values like supplier, hold reason and due date. But this overview does not display the actual issues, like the order quantity and invoice quantity.

Figure 16 Payables view of the match holds

An AP specialist then can open the invoice, and navigate to the Holds and Approvals tab. Here, you can see when the hold was placed and whether it was released, and why. If a hold condition is fixed naturally, like a Qty Rec hold where a receipt occurs, then the hold will be released by the system on the next run of Validate Payables Invoices ESS job. (note, there is an opt in that controls whether a PO change order will also trigger related invoice revalidation, which I recommend using) In this table view, you still cannot see the actual details. You must click on the Details, so they will open below.

Here we see one of the fatal flaws in how Oracle presents this information to AP! The page will only show you the details of this transaction that are on hold. Imagine the case where two invoices were sent for the same PO, and one of them has paid, leaving only one on hold. This page, already very inefficient in how information is ordered, and unable to be exported to Excel, only shows the invoice that is on hold, not the details of other invoices on hold or paid. The AP specialist has no clue that there is a second invoice at all ! They can do little more than call the Buyer — who’s name is not even displayed here, and ask for help, even though the issue of a duplicate invoice is something that only AP can assist with!

Before we move on to what the Buyers can see, look at the Details button. First, note that Oracle has two Details. The middle one is what controls visibility into the details below for the actual hold problem. The one on the right opens a DFF input window! I recommend creating a DFF that lets you store actual current information on the hold, so that if someone is working on this, they can update the details here, and report on them. But this DFF is not visible to Buyers, so it is not a wonderful way to pass information in the User Interface, though it may be, for custom reports.

Figure 17 AP Details view of Holds

Figure 18 Example of using Hold DFF to share information across teams

Buyer Hold Review

Buyers also have a dashboard with Infotiles, and they can see that PO’s have a hold. But they just see header information here, and they cannot see when an invoice is due to be paid, only PO date. While there may be a correlation, it is also possible that an old PO has a very recent invoice that has 30 days left to pay, while a newer PO has immediate terms, and the buyer cannot see which one is more urgent for AP to resolve.

To see the actual hold details, they need to click on Lifecycle Details, and then they can see the invoices and which one is on hold. But they have a tough time seeing a detailed view here, and they cannot do anything to fix the matching issues which are so prevalent. They also cannot see whether users have already been notified via Confirm Receipts process, how many times, or their responses; though if the system is configured, they may have received a notification that the item was not received.

Figure 21 Buyers can only see certain details for holds

Figure 22 Buyers view of invoice details is extremely limited

But, when you open the invoice, a buyer cannot see the Hold Details tab of the invoice at all! They are left to ascertain the type of hold and the details by comparing the lifecycle lines or working line by line to identify the issue.

Once they have identified the issue, the Buyer cannot release holds manually here in the User Interface, and releasing holds is not always the best action. If they want to fix an issue like order quantity or price, they must edit the order to create a change order, enter a description, find the line(s) that must be corrected, enter the new value, then submit for approval. Alternatively, if the issue is an incorrect match, they must ask the AP team to correct the issue.

Core Lesson for Buyer and AP Teams

Neither AP nor Buyers have the complete picture, and they must communicate and work together to resolve issues. But even here, focusing on the actual hold codes in isolation can give the wrong picture about responsibility. So, you must create custom reports, and a culture of using information, not simply data.

25A Updates Offer Improvement

In 25A, Oracle improved this process. One prerequisite is enabling the Manage Purchase Orders page in Redwood, but this can currently work alongside Classic. You can easily filter on POs with an invoice hold, and when you select the hold name, Oracle will propose the change order to fix the issue. This saves considerable time, compared to the current state where you must calculate the change order required, and enter all details manually.

However, it will not help buyers to see incorrect matching details, which are critical for Ordered Quantity holds. If a buyer does not see the other matched invoice, there could be situations where another invoice was incorrectly matched, and the PO quantity is increased incorrectly. Because this approach does not release the hold, but generates a change order, you cannot hide these types of holds by keeping holds as non-manually releasable. There is no filter to prevent buyers from searching for this hold type. The recommendation is for buyers to always validate and only create change orders when appropriate, even when they are simple to create. A report giving more details will help buyers to know when there may be a matching error, but they could also pick up the phone to call the supplier to inquire.

The best application for this new tool is for price differences, where it is expected to save considerable time, and where the issue is more likely to be resolvable simply by the buyer. However, this tool only fixes existing purchase orders, and doesn’t fix the BPA. If there is a BPA with the wrong price, that must also be fixed so that future orders don’t have the incorrect price

Figure 23 Redwood PO screen showing filters for invoice holds

Figure 24 Redwood PO Screen showing how to generate change orders to resolve holds with a single click

Retroactive Price Updates

Retroactive Price Updates is a feature with Agreements that allows a buyer to update PO’s to the new BPA price in case of an error, or a situation where the agreement price was forced to change earlier than expected. If you have a significant amount of PO Lines to update, this is a faster method than issuing the change orders individually.

On each BPA, there is a setting for whether this is enabled or not, as well as whether to

• Initiate the ESS Job automatically upon approval, or whether the ESS Job must be manually run
• Whether to reprice only the open orders with no receipts and invoices, or to update price on all orders including closed orders with receipts and invoices as well as incomplete and rejected orders.
• Whether to notify the supplier about the updated PO or not
• Note: Retroactive Price Updates do not update Consignment PO Lines, nor will it update PO’s with an open change order

Figure 27 Agreement Settings for Retroactive Price Update

Running this process manually does give you much greater control over date ranges, because on the ESS Job you can set the PO Line Requested Date value from which to use.

This feature also works alongside the new 25A feature to put a start date on the BPA Line. This also uses PO Line Requested Date to compare to the BPA Line to determine which line price is valid for use. This may reduce the benefits achieved by running the ESS Job manually and setting the start date here, because you can simply update both of the lines on the BPA, or even edit the start dates on the lines, to determine which value to use.

Key things to keep in mind is that if you change the start dates on the BPA Line, or you change the Requested Delivery Date on the PO Line, then the Source Agreement Line value on the PO may change to accommodate. There is a profile option for requested delivery date validation, and if set to yes, this will prevent submiss ion of a PO if there is no valid BPA Line for the item you are ordering, and you must disable the feature Use Order Date to Determine the Price on Purchase Orders, the legacy feature which used price break dates to determine the right price.

Invoice Validation Upon PO CO Submission

Another helpful tip is to enable this Opt In value, which will automatically re-validate invoices on a PO when a change order is submitted. If you are running Validate Payables Invoices jobs daily, even after a change order is submitted there will be a delay until the hold is removed, which can be confusing for end users. Opting in to this feature will reduce that delay.

Business Process for Resolving Holds

The chart below shows a potential approach for resolving holds. It demonstrates how Price holds may be resolved by the buyer and supplier, while Qty Ord holds require validation with Requester and Receiver; Qty Rec holds may require validation with Requester, Receiver and AP, and a line with both Qty Ord and Qty Rec type holds should be validated by AP before undertaking those other validations.

Figure 28 Flowchart for Resolving Price and Quantity holds between AP and Buyer

Reporting

Seeded Report

Oracle includes a seeded report called Payables Matching Holds Report. Most of the parameters are straightforward, except Report Type. All Validations will include system and manual holds, while Audit Report only includes system holds.

However, as you can see, the results in the report are hard to read, with multiple header label rows ahead of multiple rows of results. Additionally, it does not include important details like whether multiple invoices are matched to the same PO line, which can be a core cause of holds. Finally, it is in a PDF format unfriendly to Excel. The only use case is to present details to a support in a PDF format, but typically suppliers find the formatting less than friendly and request a custom report in an Excel format.

Figure 31 Payables Matching Hold Detail Report

Given the security and access issues across teams, and how helpful it is to speak a common language, much consideration should be given to creating custom reports, which would be used alongside the User Interface pages. Reports may include

Executive Dashboards

• Hold Aging: Count of open holds by the week they were created, and by type, to show whether holds are being closed out quickly or left to linger.
• Top Supplier Holds: A count of holds added and released by supplier organized by suppliers with greatest count of open holds. This allows you to quickly see whether the volume is reasonable and whether it is building up or being decreased over time.
• Hold Activity: A line chart showing the sum of new holds by week and type. This lets you see the inbound volume of new holds, regardless of whether they are cleared quickly or not.
• Age of Resolve Holds: A line chart showing, when a hold was resolved in each week, how old was the hold. This lets you see whether the team is only focusing on new holds, only focusing on old holds, or correctly covering all holds.

AP Specific

• Duplicate Invoices, where more than one line on the same or multiple invoices were matched to the same PO Line, where the PO Line is on hold for Qty Ord or Qty Rec. This helps to identify the root cause of the error, like a duplicate entry or a mismatch, and provides AP with all the related invoice numbers even for invoices not on hold for quicker resolution. The other recommended reports give a summary or another way of looking at data that may already be somewhat available in User Interface, but this report is a key concept that is lacking in standard Oracle interfaces. Duplicate invoices and mismatched lines are the hardest concept for buyers and AP to communicate around, and therefore this report is one of the most critical to use.

Figure 32 Example report showing all invoice lines matched to a PO line where one or more of those invoice lines are on hold for quantity ordered or received

Testing

• Current Tolerance Modeling: By setting strict tolerances, you can generate a SQL report showing for each line on hold, whether new parameters for values like Price Percentage and Maximum Schedule Amount would result in the line still being on hold or not. During test cycles, this will allow you to demonstrate how various tolerance parameters compare to current systems, in total amount of holds as well as dollar impact, and the impact of changing tolerances on actual cash flow. For example, if your tolerance for price percentage is currently 2%, and your extended schedule amount is $25, this report may show that currently, you have 3,700 lines on one or both of those holds which requires review. But, if you change the price percentage to 7% and the extended amount to $60, this would result in only 899 holds to review, and you would pay $5,300 more than the current on hold PO expectation. Then, you can determine whether (3,700-899) holds, measured in employee time, is worth more or less than the $5,300 extra you will pay.

Figure 33 Example report to model how price and schedule tolerance changes will reduce holds and the extended impact on cashflow

• Past Tolerance Modeling: Using PO Versions table, you can show the price of a line at the time of the hold. Looking at holds which were removed, you can compare the original line price with the current line price, to show whether holds were removed by updating the PO or not. This will let you estimate whether loosening the price and amount tolerances actually involve more money going out the door than otherwise; or if you just spent time investigating the hold but still ended up updating the price to match the invoice, in which case there is no money lost. This helps an organization determine whether it is a better ROI to relax tolerances or continue to investigate.

Figure 34 Example of a hold review report used to view current and historical holds for price to determine whether tolerances are appropriate

Shared Team

• Older Price Holds, a listing by date so you can prevent holds from not being resolved in a timely manner. For example, you could use the oldest hold date as a metric for your team, “Ensure all holds are resolved within 30 days”
• Price Holds where Agreement Exists, to see the BPA price and the invoice price and more easily have a conversation with suppliers about why they are not honoring BPAs. You could also use this type of data to relax tolerances and pay even when the price doesn’t match, and then revisit on a regular basis to see any overages paid and request credits.
• Invoice Hold Missing Receipt, a listing with details where there is a Qty Rec hold, but the invoice is not on the duplicate invoice listing report, a way to gauge true missing receipt details more easily

Reporting Considerations

The data for holds must be sourced from multiple tables. The notes here are intended to help a functional consultant work with a report developer more efficiently by having a basic understanding of how some of these tables related to each other, and the limitations of the individual tables.

The AP_Holds_All tab le stores hold along with invoice ID and PO Schedule ID. It does not store a status flag, but you can determine which holds are still active by checking whether there is a release date.

You can use the Schedule to identify PO Line, Header and Distribution s, and use those tables to link to Requisitions, HZ_Parties, POZ_Suppliers_V, and Per_users. You also link to AP_Invoice_Lines_All and AP_Invoices_all tables to get invoice details.

To include detail on past orders, you must use the PO_Versions table and the _Archive version of the PO tables to identify which one was effective on the hold date, compared to the current version.

Other Tools

VBAFE

Visual Builder Add In for Excel is an Oracle produced tool that leverages REST APIs to retrieve, modify or create, and push data back to Oracle, through Excel. In other words, instead of working record by record in UI, you can query a set of records in VBAFE and act on them. This does require that the holds be manually releasable, and querying is not very convenient as there is no straightforward way here to limit whether hold is active, because release code = null is not a valid search parameter. Additionally, the information that is visible via the rest api is limited. For example, you can view the PO number, but not the current PO price. This is best suited to work in hand with a BI Publisher or OTBI report that lists the details like price differences, and then you can query by a set of invoices. This tool is also useful for applying or releasing manual holds quickly. These sheets must be built by hand as Oracle only offers the tool; not complete and ready to use spreadsheets and limited support.

Figure 35 VBAFE tool for applying holds and releases

More4Apps

More4Apps is a company that offers similar spreadsheet based tools for a variety of tasks. Unlike VBAFE, they offer pre-built spreadsheets including data validation rules, and offer support for their use, making them an attractive partner for Excel based upload, download and management tools. In the case of Holds, they are using a similar method, REST API, as VBAFE. It allows you to quickly add and release holds in a similar way. But, for other tasks they make use of a different method, SOAP, that may be more powerful than REST. If you already use More4Apps, their Hold tool is a great fit with functionality to add or remove holds;

Summary of Recommendations

Approach the implementation as an opportunity for a cultural shift, where the increased collaboration between buyers and AP is a benefit. The business process is equally important as the technical tools. Use a methodology like Lean 6 Sigma to solve the root issues as a team.

Review current workload for resolving holds and take a hard, practical look at the expectation from later test cycles, using tools to demonstrate the impact on workload of other tolerance levels. If you make the work too hard on your team, you will face a rebellion, and your team will be more focused on putting our fires rather than resolving the underlying issues

During SIT and similar test cycles when PO and Invoice data is loaded, use reporting to review the invoices on hold and compare to legacy system to ensure the rules picked are relatively comparable. If in doubt, use a stricter rule that you would expect, and then use modeling reports to do a what if analysis. For example, if you use a hold rule of 5% price tolerance max, and $2 max amount, then a lot of invoices will go on hold. You can easily calculate in SQL what the actual price percentage and amount values are, and then use a Parameter to input other options; then check whether the actual results are less than your parameter. It is much harder to go the other way around.

While doing this, please consider that if you loosen tolerances, there is no way to mass re-validate and re-apply holds. If you validate invoices individually, the holds will be reapplied; but if you run the Validate Payables Invoices ESS Job, even though the documentation says it will re-apply holds, it does not. Please do not loosen tolerances unless you are sure.

Ensure that users never accidentally clear the check mark from the tolerances thinking that if the value was 0, then removing the checkbox is the same. It is not the same; a 0 tolerance means there is no variance allowed at all; while removing the checkbox means there is no inspection done at all.

Consider that it is safer to have some allowable quantity over ordered that is ok, if your quantity over received is strict; this ensures that you only pay when you did actually receive the item.

Revisit the workload and tolerances occasionally after go live to find opportunities to change them globally or by supplier. Tolerances should be examined on a regular basis, and you should run a report to show what percentage of holds were fixed by updating PO price vs. invoice price for price holds. If your in voices are fixed, then you should work with suppliers to understand why they sent incorrect invoices. If your PO’s are fixed instead, then you should question why you cannot have accurate pricing on your orders in advance and whether the extra steps involved are worth the time instead of simply paying the vendors invoice without investigation.

Place a focus on making sure Agreement Data is correct; it is always faster to do something slowly and correct once, than to do it quickly two or more times.

Implement tools like Duplicate Invoice reporting, Receipt Confirmation, price update processes, and the new 25A buyer hold update features, and keep an eye on all new releases for new tools that are available.