A purchase order and an invoice can agree while the buyer has not recorded the corresponding receipt. Goods can also have arrived without all of them being accepted after inspection. A database supporting a payment workflow needs to preserve those differences instead of treating one quantity as the answer to every matching question.
The useful starting point is the application’s selected matching policy. Different controls require different evidence. A database evaluation should identify the actual records and approval rules the workflow uses before measuring how quickly it can calculate a match.
Identify the records included by the chosen control
Oracle Procurement 26a distinguishes two-way quantity matching between purchase order and invoice, three-way matching that adds receipt quantities, and four-way matching that adds inspection-accepted quantities. Its descriptions include the applicable tolerances.
Those are defined application controls, not a universal instruction that every organization must choose the same level. The source also distinguishes the approval level from the invoice match option that selects matching to an order or receipt. A project should document its real settings rather than infer the control from a similarly named screen or a database field labelled matched.
Keep physical arrival separate from the posted receipt
Microsoft’s Dynamics 365 Finance examples include items that have arrived but whose product receipt was not posted immediately. In the example, the missing matched receipt affects the quantity check. A discrepancy therefore need not prove that goods never arrived; the workflow’s recorded evidence may be incomplete.
That distinction helps define an operational review. When an invoice cannot be matched, the responsible team should be able to identify whether it is waiting for a recorded receipt, dealing with a quantity difference, or applying another configured check. The database should support that explanation through the application’s records. A single aggregate received quantity may not provide enough context to resolve the specific invoice line.
Preserve inspection acceptance when the policy needs it
A receipt and an inspection acceptance answer different questions. In a hypothetical purchase, some delivered items are still awaiting inspection. A workflow using accepted quantities needs the applicable acceptance evidence, not an assumption that everything received is acceptable for that control.
The project should define how invoice lines relate to order, receipt, and acceptance records, including partial quantities and corrections. These are proposed data and acceptance questions, not a prescribed accounting policy. The buyer should use its own approved control and tolerances to determine the expected outcome. The database should not invent that policy from the presence of an inspection record or the name of an item.
| Workflow question | Evidence the design should identify | A misleading substitution |
|---|---|---|
| What control applies here? | The effective matching policy and tolerances | A generic match label without its selected rule |
| What quantity was received? | The relevant posted receipt evidence | An order quantity used as proof of receipt |
| What quantity was accepted? | Applicable inspection-acceptance evidence | Treating physical arrival as inspection acceptance |
| Why can processing proceed? | The checks and authorized discrepancy handling actually used | A passing calculation presented as proof of payment |
Retain the configured handling of discrepancies
Microsoft’s examples describe matching policies at different levels and conditions for approving posting with discrepancies. They should not be simplified into a claim that every mismatch universally blocks every invoice. A new implementation needs the actual approval and exception behavior, as well as the underlying quantities.
This matters during consolidation or migration. A report can display the same amounts after a move while losing the explanation for an authorized exception. A proposed pilot should therefore include an ordinary match, a receipt not yet posted, a partial acceptance case where relevant, and a discrepancy handled through the approved process. Review the resulting status and supporting evidence, not only whether the calculation completed.
Evaluate OceanBase for the records the application must maintain
OceanBase’s official repository describes its distributed relational database role. It can be assessed where a proposed application needs structured relationships among orders, receipts, inspection results, invoices, and approval evidence. That role does not establish a native Oracle Procurement or Dynamics implementation, certification for a packaged application, or automatic payment authorization.
The existing database-backed workflow should remain the comparison baseline. If a proposed change keeps a packaged application, the buyer needs evidence for that application’s supported deployment. If the change includes a new integration or custom service, its matching and approval responsibilities must be made explicit rather than attributed to the database engine.
No order, receipt, invoice, approval, or payment operation was performed for this article. The proposed acceptance result is a traceable explanation of which records agreed under which rule and how any exception was handled. That gives a database comparison a concrete business boundary while keeping a calculated match, an approved processing step, and an actual payment as distinguishable outcomes.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.