Introduction
Purchase order matching is an important part of invoice processing in Oracle Fusion Cloud Payables. It helps organizations validate supplier invoices against purchase orders and receiving transactions before payment.
However, not every business requirement can be addressed through standard matching rules.
Consider a scenario where a purchase order has been created for 10 units and the complete quantity has already been received. During invoice creation, the user matches only 4 units against the purchase order.
From a standard matching perspective, this is generally an acceptable transaction. The invoiced quantity does not exceed the received quantity.
But suppose the business requires an additional control: once the full purchase order quantity has been received, an invoice matched for a lower quantity should be placed on hold for review.
In this article, I will walk through how this requirement can be addressed using Oracle Fusion Payables, a custom invoice hold, and REST API-based validation.
The focus is on extending standard invoice controls without changing the underlying purchase order matching process.
1. Understanding the Business Requirement
Let's consider the following transaction.
| Transaction | Quantity |
|---|---|
| Purchase Order Quantity | 10 |
| Received Quantity | 10 |
| Invoice Matched Quantity | 4 |
| Quantity Difference | 6 |
The purchase order has been fully received, but the invoice has been matched for only part of the received quantity.
The business expects the system to identify this difference and apply a custom hold to the invoice.
The invoice should remain unavailable for payment until the discrepancy has been reviewed and the hold is released.
Why is an additional control required?
Oracle Payables supports partial invoicing. A supplier may legitimately invoice fewer units than those received.
For example, if 10 units have been received but the supplier invoices only 4 units, standard matching does not necessarily consider this an exception.
In this particular scenario, however, the business wants to review such transactions before payment.
The requirement is therefore not to replace standard invoice matching, but to introduce an additional validation based on the organization's invoicing policy.
2. Standard Oracle Payables Matching vs. Custom Validation
Before configuring the solution, it is important to distinguish between standard matching and the proposed custom control.
Oracle Fusion Payables supports different matching options, including two-way, three-way, and four-way matching.
Under three-way matching, the invoice is validated against purchase order and receipt information, subject to the configured matching rules and tolerances.
Standard quantity matching is primarily concerned with situations where invoiced quantities exceed the permitted ordered or received quantities.
In our example:
Received Quantity = 10
Invoiced Quantity = 4
The invoiced quantity is lower than the received quantity.
Therefore, a standard quantity matching hold would not normally be applied solely because of this difference.
The custom requirement is different:
If the invoiced quantity is less than the applicable received quantity, identify the transaction and place the invoice on hold for review.
This condition will be evaluated through a custom integration.
3. Solution Design
The proposed solution involves Oracle Fusion Procurement, Receiving, Payables, and REST APIs.
The overall process is:
The REST API integration will be responsible for retrieving the required information, performing the comparison, and applying the configured invoice hold.
4. Create the Purchase Order
The first step is to create a purchase order in Oracle Fusion Procurement.
For this demonstration, I will use a single purchase order line with a quantity of 10 units.
| Attribute | Value |
|---|---|
| Purchase Order | US165400 |
| Item | Item001 |
| Quantity | 10 Units |
| Unit Price | $40 |
| Total Amount | $400 |
After entering the required details, submit the purchase order for approval.
Once approved, the purchase order will be available for receiving.
Screenshot 1: Approved Purchase Order with Quantity of 10 Units
5. Complete the Receiving Transaction
The next step is to perform the receiving transaction against the purchase order.
For this scenario, the complete quantity of 10 units will be received.
The transaction will have the following details:
| Description | Quantity |
|---|---|
| Ordered Quantity | 10 |
| Received Quantity | 10 |
| Remaining Quantity to Receive | 0 |
The receipt must be successfully processed before proceeding with invoice matching.
This is important because the custom validation will compare the invoiced quantity with the applicable received quantity.
Screenshot 2: Receipt Completed for 10 Units
6. Create the PO-Matched Payables Invoice
Once the receiving transaction is completed, navigate to Oracle Fusion Payables.
Navigation:
Payables → Invoices → Create Invoice
Create an invoice for the supplier and select the purchase order for matching.
Although the purchase order has been received for 10 units, enter an invoice quantity of 4 units.
Assuming a unit price of $100, the invoice amount will be $400.
| Attribute | Value |
|---|---|
| Invoice Number | INVOICE_101 |
| Purchase Order | US165400 |
| Received Quantity | 10 |
| Invoice Quantity | 4 |
| Invoice Amount | $400 |
Save the invoice and complete the applicable matching steps.
At this point, the invoice is matched for a quantity lower than the received quantity.
Under standard matching rules, this difference alone would not normally result in a quantity matching hold.
Our custom validation will now evaluate the transaction.
Screenshot 3: Payables Invoice Matched for 4 Units
7. Configure the Custom Invoice Hold
The next step is to define a custom invoice hold in Oracle Fusion Payables.
Navigation:
Setup and Maintenance → Manage Invoice Holds and Releases
For this scenario, the proposed hold name is:HB_Invoice_Hold
Partial PO Invoice Quantity Hold
The hold will be used to identify invoices that require additional review because the matched invoice quantity is lower than the received quantity.
A user-defined hold name can be associated with a supported hold type, such as Invoice Hold Reason.
The hold configuration should be reviewed to determine whether accounting is permitted while the invoice is on hold.
For this example, the primary requirement is to restrict payment processing.
One important distinction is that defining a hold name does not automatically evaluate the difference between invoiced and received quantities.
The custom integration will perform that validation and explicitly apply the configured hold.
Screenshot 4: Custom Invoice Hold Configuration
8. Retrieve Invoice Details Using REST API
Once the invoice is created, the integration needs to retrieve the relevant invoice information.
Oracle Fusion Cloud Financials provides REST APIs for accessing Payables invoice data.
The Payables Invoices REST resource can be accessed using the following endpoint:
GET /fscmRestApi/resources/11.13.18.05/invoices
The integration should identify the invoice using the appropriate invoice reference and retrieve its matched line information.
The required business data includes:
- Invoice identifier
- Invoice number
- Purchase order reference
- Purchase order line or schedule reference
- Matched invoice quantity
The quantity should be retrieved from the relevant invoice line or matching information, rather than assuming it is an invoice header attribute.
For this scenario, the matched invoice quantity is 4 units.
Screenshot 5: REST API Response Showing Invoice Details
9. Retrieve the Receiving Quantity
The integration also needs to retrieve the receiving information associated with the purchase order.
The required information includes the purchase order reference, receiving transaction details, and applicable received quantity.
For our example:
Purchase Order: PO-1001
Received Quantity: 10 Units
The integration must ensure that the invoice quantity and received quantity belong to the same purchase order matching reference.
This becomes particularly important when a purchase order contains multiple lines, schedules, or receipts.
For the current demonstration, we are considering a single purchase order line with one completed receipt.
Screenshot 6: Receiving Information Retrieved Through REST API
10. Perform the Custom Quantity Validation
Once the invoice and receiving quantities have been retrieved, the integration will compare them.
The validation condition is:
IF Invoiced Quantity < Received Quantity
THEN
Identify Invoice for Custom Hold
ELSE
No Custom Hold Required
For our example:
Received Quantity = 10
Invoiced Quantity = 4
Quantity Difference = 6
Since 4 is less than 10, the condition is satisfied.
The invoice will therefore be identified for custom hold processing.
This validation represents the business requirement rather than standard Oracle Payables matching behavior.
For a production implementation, the rule should also define whether the comparison is based on the current invoice or cumulative quantities across all relevant invoices.
11. Apply the Invoice Hold Using REST API
Oracle Fusion Cloud Financials provides an Invoice Holds REST resource that supports creating and managing invoice holds.
The create operation uses:
POST /fscmRestApi/resources/11.13.18.05/invoiceHolds
The integration will use the appropriate invoice identifier and configured hold name to apply the hold.
For this scenario:
| Attribute | Value |
|---|---|
| Invoice | INVOICE_101 |
| Hold Name | Partial PO Invoice Quantity Hold |
| Received Quantity | 10 |
| Invoiced Quantity | 4 |
| Quantity Difference | 6 |
| Expected Action | Apply Invoice Hold |
The actual request payload must follow the Oracle REST API schema supported by the environment.
Before creating a hold, the integration should check whether the same active hold already exists against the invoice.
This avoids creating duplicate holds if the integration is executed more than once.
Once the request is processed successfully, the integration should capture the response and verify that the hold was created.
Screenshot 7: REST API Request and Successful Response
12. Verify the Invoice Hold in Payables
After applying the hold through REST API, navigate back to Oracle Fusion Payables.
Navigation:
Payables → Invoices → Manage Invoices
Search for the invoice and open the Holds section.
The expected result is:
| Description | Expected Result |
|---|---|
| Invoice Number | INVOICE_101 |
| Invoice Quantity | 4 Units |
| Received Quantity | 10 Units |
| Custom Hold | Applied |
| Payment Processing | Restricted |
The custom hold should be visible against the invoice.
The invoice will remain restricted from payment while the hold is active.
It is important to distinguish this from preventing further invoice entry. A manual invoice hold does not, by itself, prevent users from editing invoices or creating additional invoices against the purchase order.
If the business requires those restrictions, they must be addressed separately.
Screenshot 8: Custom Hold Visible Against the Invoice
13. Release the Invoice Hold
The final step is to define how the invoice hold will be released.
The hold should remain active until the quantity difference has been reviewed and the required business action has been completed.
For example, the supplier may submit another invoice for the remaining quantity, or the existing invoice may require correction.
The integration should not assume that receiving or invoicing additional quantities automatically releases a manually applied hold.
The release process must be explicitly designed and tested.
Depending on the business requirement, the hold may be released manually by an authorized user or through the supported REST API functionality.
Screenshot 9: Invoice Hold Released After Review
14. Additional Considerations for Production Implementation
The example above uses a single purchase order line to explain the process.
In actual implementations, there are several additional conditions to consider.
Multiple Purchase Order Lines
The integration should compare quantities at the appropriate purchase order line or schedule level.
Comparing only purchase order header totals may lead to incorrect results.
Multiple Receiving Transactions
A purchase order line may be received through several transactions.
The calculation should consider the applicable net received quantity, including corrections and returns where required.
Multiple Payables Invoices
A supplier may submit multiple invoices against the same purchase order.
The business must decide whether the hold should be based on the current invoice quantity or cumulative invoiced quantity.
Duplicate Hold Prevention
The integration should check for an existing active hold before applying another hold to the same invoice.
Integration Timing
The timing of the REST API validation is important.
If the integration runs after invoice creation, the business must ensure that the invoice cannot be paid before the validation and hold application have completed.
Hold Release Controls
The release process should be documented and restricted to the appropriate users or integration process.
These considerations become important when moving the solution from a demonstration scenario to a production environment.
Key Takeaways
The main points from this scenario are:
- Oracle Fusion Payables generally supports partial invoicing against purchase orders.
- Standard matching does not normally place an invoice on hold simply because the invoiced quantity is lower than the received quantity.
- A custom invoice hold can be configured to support an additional business review requirement.
- REST APIs can be used to retrieve invoice information, compare quantities, and apply the configured hold.
- The custom validation should use the appropriate purchase order matching references.
- Hold creation, duplicate prevention, and release should be considered as part of the overall integration design.
- A manual invoice hold restricts payment but does not automatically prevent additional invoice entry or editing.
Final Thoughts
In this article, I have covered a business scenario where a purchase order is created for 10 units, the complete quantity is received, but the Payables invoice is matched for only 4 units.
While Oracle Fusion Payables generally allows this type of partial invoicing, some organizations may require an additional review before allowing the invoice to proceed to payment.
The proposed solution uses REST APIs to retrieve the invoice and receiving information, compare the quantities, and apply a configured invoice hold when the business condition is satisfied.
The important part of this approach is understanding where standard Oracle matching ends and where a business-specific validation needs to be introduced.
This is particularly relevant when implementing additional financial controls without changing the standard purchase order and invoice matching process.
Have you worked on similar invoice validation requirements in Oracle Fusion Payables? Feel free to share your experience or connect with me to discuss other approaches.
