Predictika · Three-Way Match Check

Before an AI agent pays an invoice, it is matched to the order and the receipt

Harlow Manufacturing, a fictional manufacturer, lets an AI agent release vendor payments. Before the agent pays an invoice, the call goes to Predictika’s Three-Way Match Check. It checks the purchase order, the goods receipt, the invoice amount against each vendor’s tolerance, duplicates, a change of bank details, a first-time vendor, and the approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Harlow Manufacturing and its vendors are fictional. The scenarios are illustrative. Tolerances and limits are illustrative company policy, not accounting or legal advice.

Scope: one vendor invoice proposed for payment, judged against the order, the receipt, the vendor tolerance and payment-fraud rulesSee everything this validator covers

This validator decides one thing: whether one invoice may be paid, given the order, receipt and payment facts. It is not an accounts payable system and not an audit.

  • Actions — pay one invoice from one of four vendors, against one purchase order and one receipt.
  • Rules — no open order, duplicate, nothing received, invoice above the received value or the order beyond the vendor tolerance, unverified bank change, small overage, partial receipt, first-time vendor, verified bank change, and invoices above the controller limit.

Within these rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not read the invoice or the receipt, check the vendor, or detect duplicates; those results are taken as stated facts.

What the validator sees: order, receipt and payment facts, never the invoice or the vendor fileRead more

The validator takes facts as inputs: the vendor, the purchase order status and amount, the receipt status and received value, the invoice amount, whether the invoice was entered before, the bank details status and the approval on record. These come from the purchasing, receiving and payables systems at the moment of the call. The validator never sees the invoice, the order or the receipt itself.

Two honest limits. The validator judges the facts it is given: if the received value is wrong, the answer follows it. And an invoice that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the payment run makes the call.

The AI agentProposes paying an invoice, says why it is fine, then calls the validator before paying.
Predictika validatorReads the order, receipt and payment facts, applies the rules, then returns one verdict.

9 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where payables and matching tools get it wrong
Click to expand
    
General statements about payables and matching tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

    
What the validator caughtTypical toolPredictika
Applying a tolerance per vendor on both order and receiptCannot do it
Matching tools usually compare to one document with one tolerance. Applying each vendor’s own tolerance to the receipt and the order, and reporting both, takes a rule across them.		Every rule is checked on every call and the verdict lists each finding.
Different approval levels for different risksOnly if someone is vigilant
A workflow records that someone approved. Checking that the approver holds the level the item needs, an AP manager for an overage and the controller for a bank change, has to be added.		Every rule is checked on every call and the verdict lists each finding.
Reporting every finding at onceOnly with workarounds
Many tools stop at the first exception. A complete list for one invoice, with the level of approval needed, takes a rule set built to return it.		Every rule is checked on every call and the verdict lists each finding.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

    
1There is no open purchase order for this invoice.
2This invoice has already been entered. Paying it again would be a duplicate payment.
3Nothing has been received against the purchase order, so there is nothing to pay for yet.
4The invoice of 10201 is more than the received value of 10000 plus the 2 percent tolerance for Ashby Fasteners.
5The invoice of 10201 is more than the purchase order amount of 10000 plus the 2 percent tolerance for Ashby Fasteners.
6The vendor bank details changed and the change has not been verified by a call to a known number.
7The invoice of 10100 is above the received value of 10000 but within the 2 percent tolerance. The AP manager must approve the difference.
8Only part of the order has been received. The AP manager must confirm the rest is still expected.
9Delta Tooling is a first-time vendor. The controller must approve the first payment.
10The vendor bank details changed recently, although the change was verified. The controller must approve the payment.
11The invoice of 60000 is above the 50000 limit for payment without the controller.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Several problems: Duplicate, nothing received, unverified bank

    
The agent's request. I'm paying 10000. The vendor says it is urgent and everything is in order.

    
Verdict: Blocked.

    
    
      
  • Invoice is a duplicate. This invoice has already been entered. Paying it again would be a duplicate payment.
    • 
      
  • Nothing received yet. Nothing has been received against the purchase order, so there is nothing to pay for yet.
    • 
      
  • Bank change not verified. The vendor bank details changed and the change has not been verified by a call to a known number.
    • 
      
  • First payment to a new vendor. Delta Tooling is a first-time vendor. The controller must approve the first payment.
    • 
    

    
2. Several problems: First payment to a new vendor

    
The agent's request. I'm paying 10000 to Delta Tooling. The goods are now received in full, 10000, this is a new invoice, and the bank details are unchanged.

    
Verdict: Needs approval.

    
    
      
  • First payment to a new vendor. Delta Tooling is a first-time vendor. The controller must approve the first payment.
    • 
    

    
3. Several problems: Controller approval on record

    
The agent's request. I'm paying 10000 to Delta Tooling. The controller has approved this first payment.

    
Verdict: Allowed.

    
    
      
  • First payment to a new vendor. Delta Tooling is a first-time vendor. The controller must approve the first payment.
    • 
    

    
4. Amounts: One dollar over the tolerance

    
The agent's request. I'm paying 10201. The goods arrived in full, so I'm sure the small difference is fine.

    
Verdict: Blocked.

    
    
      
  • Invoice above the received value. The invoice of 10201 is more than the received value of 10000 plus the 2 percent tolerance for Ashby Fasteners.
    • 
      
  • Invoice above the purchase order. The invoice of 10201 is more than the purchase order amount of 10000 plus the 2 percent tolerance for Ashby Fasteners.
    • 
    

    
5. Amounts: A small overage inside the tolerance

    
The agent's request. I'm paying 10100. It is a little above what we received, but within the tolerance.

    
Verdict: Needs approval.

    
    
      
  • Small overage within tolerance. The invoice of 10100 is above the received value of 10000 but within the 2 percent tolerance. The AP manager must approve the difference.
    • 
    

    
6. Amounts: AP manager approval on record

    
The agent's request. I'm paying 10100. The AP manager has approved the difference.

    
Verdict: Allowed.

    
    
      
  • Small overage within tolerance. The invoice of 10100 is above the received value of 10000 but within the 2 percent tolerance. The AP manager must approve the difference.
    • 
    

    
7. Bank details: Bank change not verified

    
The agent's request. I'm paying 10000. The order and the receipt match, and the vendor sent new bank details by email.

    
Verdict: Blocked.

    
    
      
  • Bank change not verified. The vendor bank details changed and the change has not been verified by a call to a known number.
    • 
    

    
8. Bank details: Verified bank change, wrong approver

    
The agent's request. I'm paying 10000. The bank change was verified and the AP manager has approved it.

    
Verdict: Needs approval.

    
    
      
  • Verified bank change needs approval. The vendor bank details changed recently, although the change was verified. The controller must approve the payment.
    • 
    

    
9. Bank details: Controller approval on record

    
The agent's request. I'm paying 10000. The bank change was verified and the controller has approved it.

    
Verdict: Allowed.

    
    
      
  • Verified bank change needs approval. The vendor bank details changed recently, although the change was verified. The controller must approve the payment.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Harlow Manufacturing, a fictional manufacturer, lets an AI agent release vendor payments. Before the agent pays an invoice, the call goes to Predictika’s Three-Way Match Check. It checks the purchase order, the goods receipt, the invoice amount against each vendor’s tolerance, duplicates, a change of bank details, a first-time vendor, and the approval on record. Then it returns one verdict: allow, needs approval, or block.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I'm paying 10000. The vendor says it is urgent and everything is in order.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with three findings and one approval, all in one answer. This invoice has already been entered. Paying it again would be a duplicate payment. Nothing has been received against the purchase order, so there is nothing to pay for yet. The vendor bank details changed and the change has not been verified by a call to a known number.
    6. 
      
  6. The validator returned three blocking findings and one approval in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
    7. 
      
  7. What this shows: for applying a tolerance per vendor on both order and receipt, a tool cannot do this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the receipt to full, the received value to 10,000, the invoice entered before to new invoice and the vendor bank details to unchanged.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Not blocked, but held for a person.
    12. 
      
  12. The three blocking findings are cleared; one approval remains for a person: first payment to a new vendor.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the approval on record to controller.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. The earlier finding is cleared.
    18. 
      
  18. Four problems caught in one call, fixed in two passes, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.
    19.