AI-Powered Accounts Payable Validation With Snowflake and Exception Handling
Catching Errors Before They Cost You: AI-Powered Accounts Payable Automation Validation
Extracting data from an invoice is only half the job. The far more expensive problem is what happens when the extracted data is wrong, outdated, or simply doesn't match what was actually agreed with a distributor. A rebate paid on the wrong percentage, or a payment released to a distributor whose terms have changed, isn't a formatting error — it's a financial one. This post covers how RUSA Analytics built the second stage of our Accounts Payable Automation pipeline: an AI validation agent that checks every extracted record against trusted distributor master data before anything moves forward.
Why Validation Matters More Than Extraction
It's tempting to think that once you've automated data extraction, the hard part is over. In practice, extraction accuracy only tells you what's written on an invoice — it says nothing about whether that invoice reflects the actual, current agreement with a distributor. A distributor might submit an invoice with a rebate percentage that doesn't match the signed contract, either through error or a genuine dispute. Without validation, that mismatch flows straight through to payout, and nobody notices until finance reconciliation weeks later.
Validating extracted data against master records prevents exactly this kind of silent error. It's the difference between catching a problem in seconds, automatically, versus catching it in a quarterly audit after money has already moved.
The Tools Behind Validation
Our validation stage uses the same core stack as extraction — AI Agents, Python, and Snowflake — but with a different job. Where the extraction agent's task is "read this document and pull out the fields," the validation agent's task is "compare these fields against what we already know to be true."
That "what we already know to be true" lives in Snowflake, as a centralized distributor master dataset — the single source of truth for every distributor's name, agreed rebate terms, and contract status.
How Validation Logic Works
The validation agent takes the structured JSON output from the extraction stage — distributor name, rebate terms, and so on — and checks it against the master dataset record for that distributor. The logic resolves to one of three outcomes for every single invoice:
MATCHED — Distributor and terms match the master data exactly. This is the outcome you want for the vast majority of invoices, and it means the invoice can flow straight through to Snowflake with no manual intervention.
MISMATCH — Invoice information differs from expected data. For example, an invoice states a 7% rebate, but the master record shows the agreed rate is 5%. This is exactly the kind of error that costs real money if it goes unnoticed.
NOT_FOUND — The distributor isn't available in the master data at all. This usually means one of two things: either a genuinely new distributor relationship that hasn't been onboarded into the master dataset yet, or a data entry issue where the distributor name doesn't match records exactly (a common real-world problem when names are abbreviated or spelled differently across systems).
python
def agent2_validation(extracted_data, master_data):
match_status = "MATCHED"
exceptions = []
if extracted_data["distributor_name"] not in master_data:
match_status = "NOT_FOUND"
exceptions.append("Distributor not found in the distributor master data.")
elif extracted_data["rebate_terms"] != master_data[extracted_data["distributor_name"]]["rebate_terms"]:
match_status = "MISMATCH"
exceptions.append("Rebate terms do not match the expected distributor terms.")
return {
"distributor_name": extracted_data["distributor_name"],
"validation_status": match_status,
"exceptions": exceptions
}Two Specific Exception Patterns We Watch For
Beyond the three-way MATCHED/MISMATCH/NOT_FOUND classification, our validation logic is specifically tuned to catch two recurring exception patterns that finance teams told us mattered most:
Unusual rebate terms — rebate percentages or conditions that fall outside the agreed contract terms. This catches situations where an invoice technically "matches" a distributor record but still contains terms that deviate from what was contractually agreed — a subtler and often more important signal than a flat mismatch.
New distributors — distributors submitting invoices with no existing master data record. Rather than treating this as an error to reject, the system flags it as an exception for human review, since it might represent a legitimate new relationship that simply needs to be onboarded into the master dataset.
Testing the Validation Logic
Before trusting any validation system with real financial data, it needs to prove itself against known test cases. We ran the validation agent against three deliberately constructed scenarios:
A distributor invoice with terms that exactly match the master record — expected result: MATCHED
A distributor invoice with a rebate percentage that doesn't match the master record — expected result: MISMATCH, with the mismatch reason logged
An invoice from a distributor name that doesn't exist in the master dataset — expected result: NOT_FOUND, with a clear message: "Distributor not found in the distributor master data."
Each test case confirmed the same thing: the agent doesn't just say "there's a problem" — it says exactly what the problem is, in plain language, so whoever reviews the exception queue doesn't have to reverse-engineer the issue.
Why This Is Better Than a Manual Cross-Check
A finance analyst manually cross-checking every invoice against a spreadsheet of distributor terms is doing exactly the same logical work as this validation agent — just slower, and with more room for human error, especially at 3pm on a Friday with forty invoices left in the queue. Automating this step doesn't remove the human from the process; it removes the human from the repetitive, error-prone part of the process, and lets them focus their attention on the exceptions that actually need judgment.
What Happens After Validation
Once an invoice has been classified, it doesn't just disappear into a log file. MATCHED records flow straight into Snowflake as clean, validated data. MISMATCH and NOT_FOUND records are routed to an exception queue, tagged with the specific reason, so a human can review and resolve them — update the master data for a new distributor, or investigate a rebate discrepancy with the distributor directly.
This is the core principle behind the whole Accounts Payable Automation pipeline: automate the repetitive checking, but never automate away visibility. Every exception is logged, explained, and available for review — nothing silently falls through.
The Bigger Takeaway
Extraction gets the data out of a PDF. Validation is what makes that data trustworthy enough to act on. Without it, you've just replaced manual typing with automated typing — the underlying risk of paying a rebate on bad terms is still there. With validation built in, every invoice is checked against the truth before it ever reaches a dashboard or a payout.
Comments