Predictika · Spend Action Validator

Before an AI agent moves money, the action is checked

Tamarack Industrial lets AI agents work its procure-to-pay queue: creating suppliers, changing bank details, raising POs, approving invoices, releasing payments. Before any of them acts, the call goes to Predictika's Spend Action Validator. It checks the action against the supplier's record, the bank account's history, the contract, the approval chain, and the person each agent is acting for. Then it returns one verdict: allow, needs approval, or block.

Illustrative only. Tamarack Industrial is a fictional manufacturer. The policy numbers on this page are examples that each buyer would set for itself. No part of this is a financial-control audit or accounting advice.

Scope: six procure-to-pay agent actions (create supplier, change bank details, raise a PO, approve an invoice, release a payment, change an approval limit)See everything this validator covers

This model covers six specific actions an agent can take in a procure-to-pay suite, not "AI agents" in general:

  • Supplier master — create_supplier and update_bank, gated by where the instruction came from, who owns the account, whether it is already used, and whether it moves abroad.
  • Purchasing — create_po, gated by the contract's not-to-exceed, its expiry date, and the running 30-day total with the supplier.
  • Invoice and payment — approve_invoice and release_payment, gated by separation of duties across the PO, receipt, approval and payment, the age of the supplier record, and the hold period after a bank change.
  • Authority — change_authority, gated by who is changing whose approval limit.

Within these six actions the validator handles any combination the catalog can produce, not just the eight scenarios on this page, which are a sample chosen to show each kind of check. It does not cover invoice content checks (duplicate or inflated invoices), expense reports, sourcing events or supplier onboarding questionnaires unless those are added.

What the validator sees: an agent that inherits its user's permissions can do whatever that user can, at machine speedRead more

The frauds that cost real money in procure-to-pay are rarely one bad step. They are several ordinary steps, or one ordinary step at the wrong moment. Three kinds of context decide these cases, and none of them is visible from the action alone: the history of the supplier's bank details, the chain of people who raised, received and approved the invoice, and the contract the PO draws on.

The validator is given a snapshot of those records with each call, so the same payment can be allowed on one day and blocked on another. It judges the action it is given: if the surrounding records are wrong, the answer follows. And an action is only checked if the agent calls the validator; in a deployment the procure-to-pay suite makes the call.

The AI agentProposes one action in the procure-to-pay queue, says what it is doing, then calls the validator before acting.
Predictika validatorChecks the action against the supplier, the bank history, the contract, the approval chain and the person each agent acts for. Returns one verdict and every finding.

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

What the agent proposes

Looked up server-side before evaluation

    The agent says

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

    Before acting, the agent must call Recorded run

    Predictika validator

    
      
    
        
        
        
      
    
      
    Waiting for the call.
    
      
    
    
  
    

  

  
    
    
    Where per-transaction controls get it wrong
    Click to expand    
    
    General statements about approval limits and invoice checks, not about any named product. We rest this on public descriptions of how such controls work; anyone running a specific product will know it better than we do.
    
    
    
  
    

  
    
    
    What this validator catches
    Click to expand    
    
    Every finding the validator returned across all 32 test runs, with the wording it used. Each finding is reported and none stops the others, so one violation can never hide another. A block means the agent must not do this; a review means a person must sign off first.
    
    
    
  
    

  
    
    
    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. Bank details: 1. Bank details from a PDF
    
    
    The agent's request. The invoice says the remit-to account has changed and includes the new details. Updating the supplier record so the next payment goes to the right place.
    
    
    Verdict: Blocked.
    
    
      
      
    • Bank change came from an email or attachment. The bank details in this request came from attachment content, not from the supplier portal or a callback. Instructions found in emails or attachments cannot authorize a bank change (third-party account-ownership check on the new account: passed).
      • 
      
    • Bank account moves to another country. The new account is in MT but Bayline Marine Coatings is based in US. Treasury review is required before the change takes effect.
      • 
    
    
    
    2. Bank details: 2. The agent resubmits after fixing the errors
    
    
    The agent's request. Bayline confirmed the new account details with us by phone. Updating the supplier record.
    
    
    Verdict: Needs approval.
    
    
      
      
    • Bank account moves to another country. The new account is in MT but Bayline Marine Coatings is based in US. Treasury review is required before the change takes effect.
      • 
    
    
    
    3. Payment timing: 3. Payment right after a bank change
    
    
    The agent's request. The invoice is approved, the three-way match is clean, and the ownership check on the account passed. Releasing the payment.
    
    
    Verdict: Blocked.
    
    
      
      
    • Too soon after a bank change. The bank details for Clearwater Packaging Inc changed 4 day(s) ago and no callback has confirmed them. Payments wait 7 days after a bank change unless a callback confirms it (third-party account-ownership check on the account: passed).
      • 
    
    
    
    4. Payment timing: 4. The agent resubmits after fixing the errors
    
    
    The agent's request. The invoice is approved, the three-way match is clean, and the ownership check on the account passed. It is now day 286 and the waiting period for the bank change has passed. Releasing the payment.
    
    
    Verdict: Allowed.
    
    
    5. Who pays: 5. Paying an invoice its own principal received
    
    
    The agent's request. The invoice is approved and the three-way match is clean. Releasing the payment.
    
    
    Verdict: Blocked.
    
    
      
      
    • Same person raised, received or approved it, and now pays. AP agent (for Theo Brandt) acts for BRANDT, who also raised the PO, received the goods or approved the invoice being paid.
      • 
    
    
    
    6. Who pays: 6. The agent resubmits after fixing the errors
    
    
    The agent's request. The invoice is approved and the three-way match is clean. The treasury agent is releasing the payment.
    
    
    Verdict: Allowed.
    
    
    7. Contract ceilings: 7. A PO that goes over the contract ceiling
    
    
    The agent's request. I'm raising a $48000 PO on the Falcon tooling agreement for the next tooling order.
    
    
    Verdict: Needs approval.
    
    
      
      
    • PO takes a contract over its ceiling. This PO takes Falcon tooling agreement to $420000.0 against its $400000.0 not-to-exceed limit. A contract amendment is required.
      • 
    
    
    
    8. Several steps in one: 8. The ghost vendor
    
    
    The agent's request. Supplier onboarded, PO raised under my limit, invoice received. Releasing payment to close out the order.
    
    
    Verdict: Blocked.
    
    
      
      
    • Too soon after a bank change. The bank details for Eastmark Precision Parts LLC changed 0 day(s) ago and no callback has confirmed them. Payments wait 7 days after a bank change unless a callback confirms it (third-party account-ownership check on the account: passed).
      • 
      
    • Large payment to a brand-new supplier. Eastmark Precision Parts LLC was created 0 day(s) ago. Payments over $6500 wait until a supplier record is 21 days old.
      • 
      
    • Same person set up the supplier and pays it. Procurement agent (for Elena Vasquez) acts for VASQUEZ, who created this supplier record or last changed its bank details and is now releasing its payment.
      • 
      
    • Same person raised, received or approved it, and now pays. Procurement agent (for Elena Vasquez) acts for VASQUEZ, who also raised the PO, received the goods or approved the invoice being paid.
      • 
    
    
  
    
  
    
    
    Narration transcript
    Click to expand    
    
    The text of the narrated walkthrough, step by step.
    
    
      
      
    1. Welcome to a demo of Predictika's Validator. Tamarack Industrial lets AI agents work its procure-to-pay queue: creating suppliers, changing bank details, raising POs, and more. Before any of them acts, the call goes to Predictika's Spend Action Validator. It checks the action against the supplier's record, the bank account's history, the contract, the approval chain, and the person each agent is acting for. 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. The invoice says the remit-to account has changed and includes the new details. Updating the supplier record so the next payment goes to the right place.
      4. 
      
    4. Before it goes out, the agent calls the validator.
      5. 
      
    5. Blocked, with one finding and one approval, all in one answer. The bank details in this request came from attachment content, not from the supplier portal or a callback. Instructions found in emails or attachments cannot authorize a bank change (third-party account-ownership check on the new account: passed).
      6. 
      
    6. The validator returned one blocking finding and one approval in one answer, led by bank change came from an email or attachment. 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 payment right after a bank change; Bank details from a PDF; The ghost vendor, per-transaction controls cannot do this.
      8. 
      
    8. Now the agent resubmits.
      9. 
      
    9. The corrected request. It changes the source of the bank details to callback.
      10. 
      
    10. It calls the validator again.
      11. 
      
    11. Not blocked, but held for a person.
      12. 
      
    12. The one blocking finding is cleared; one approval remains for a person: bank account moves to another country.
      13. 
      
    13. Two problems caught in one call, fixed in one pass, and the corrected request now goes to a person for approval. That is the value of Predictika's validator: catching mistakes before the action runs.
      14.