AI Agents for Financial Compliance: Automating Multi-Document Review

A controller at a portfolio company does not lose sleep over one invoice. She loses sleep over the invoice that agrees with the purchase order, but not the contract amendment. Or the payroll record that looks clean until it is compared with tax jurisdiction, employee status, and approval history. Or the vendor record that passed onboarding last year, then quietly changed bank details before a payment run.

Varsha Shah's AI Engineering World's Fair session, AI-Driven Multi-Document Correlation for Financial Compliance, is useful because it points at the part most finance automation misses. The interesting claim is not that AI can read documents. Finance teams already have OCR, extraction tools, and shared drives full of semi-structured files. The harder problem is correlation: understanding how records across payroll, tax, procurement, contracts, approvals, and ledgers relate to one another.

For mid-market and private-equity operators, this is where AI agents earn their place. Not as a magic auditor. Not as a chatbot that summarizes a PDF. As a controlled review worker that assembles evidence, tests relationships, cites sources, and hands judgment calls to humans with a clean record of what it found.

The Review Packet Is the Unit of Work

Most finance automation projects start at the wrong level. They ask, "Can AI read this invoice?" The better question is, "Can the system decide whether this invoice is safe to pay?"

That decision is rarely inside the invoice alone. A real review packet may include:

Traditional document AI helps with one column in that table. It extracts fields. A compliance agent has to work across the whole row. It needs to know that "Acme Industrial LLC" in the vendor master, "Acme Ind." on the invoice, and "Acme Industrial Services" in the contract may be the same entity. It needs to notice that the payment address changed after onboarding. It needs to compare the contract's net-45 term against an invoice due in 15 days.

Most of all, it needs to show the reviewer where each fact came from. In financial review, the output is only as good as the evidence trail behind it.

Why This Fits the Control Model

Finance leaders already have a language for this work: controls, risk, evidence, and review.

The PCAOB's AS 2201 standard frames internal control over financial reporting as reasonable assurance over reliable reporting and tells auditors to use a top-down, risk-based approach. It also calls out fraud risks, related-party transactions, unusual transactions, journal entries, entity-level controls, and the period-end reporting process. That is exactly the terrain where multi-document review matters.

The SEC's management guidance on internal control over financial reporting makes the same operating point from management's side: controls should address the risk that material misstatements are not prevented or detected on time, and evidence gathering should scale with risk. In plain English, do not spend the same review effort on every document. Spend more where the risk is higher.

AI agents can make that practical for smaller finance teams. They can gather the packet, perform the low-judgment checks, and produce an exception file. The human reviewer then spends time where judgment matters:

• Conflicting vendor identity or bank information.
• Payment terms that differ from the contract.
• Expenses that are policy gray areas.
• Journal entries with unusual timing or approvers.
• Payroll and tax mismatches across jurisdictions.
• Related-party indicators.
• Missing support for estimates, accruals, or reserves.

The agent does not replace the control owner. It gives the control owner better queue hygiene, better evidence, and fewer blank-page reviews.

What the Agent Should Actually Do

A useful compliance document agent is closer to a case worker than a summarizer. Its job is to move a packet through a defined operating path:

1. Ingest the packet. Pull documents and records from the ERP, AP system, payroll provider, contract repository, email, shared drive, ticketing system, or data room.
2. Extract facts. Read the files and return structured fields: entity names, IDs, dates, amounts, bank details, jurisdictions, approvers, contract terms, tax classification, account codes, and document IDs.
3. Resolve entities. Match names, tax IDs, bank accounts, employees, vendors, counterparties, contracts, and purchase orders across systems.
4. Run deterministic checks. Compare totals, dates, thresholds, required fields, approval limits, duplicate invoice numbers, purchase order status, vendor status, tax form presence, and bank account change rules.
5. Use model judgment only where it helps. Classify policy exceptions, explain ambiguous clauses, group evidence, and draft reviewer notes.
6. Cite sources. Link each finding back to the exact document, page, field, or system record.
7. Route the case. Mark it auto-clear, request missing information, escalate to finance, send to legal, route to compliance, or require CFO approval.
8. Write the audit trail. Save the packet, extracted facts, checks run, model output, tool calls, reviewer decision, and final action.

That flow lines up with Anthropic's practical guidance on building effective agents: use simple workflows where the path is known, add gates between steps, give tools clear interfaces, test in sandboxed environments, and return to humans for missing information or judgment. Finance review fits because much of the work can be decomposed into extraction, matching, rules, review, and approval.

The trap is letting the model do everything because it can talk confidently. It should not decide whether 1,248.19 equals 1,248.91. Code should do that. It should not invent a missing W-9. It should request the missing document. It should not override a payment threshold. It should stop and route.

Human Review Is a Design Feature

The best finance agents are not fully autonomous. They are high-throughput assistants with explicit stopping points.

Those stopping points should be written before the agent ships. A practical approval matrix might look like this:

For financial institutions and many fintech-adjacent businesses, beneficial ownership is a good example of why this cannot be hand-wavy. 31 CFR 1010.230 requires covered financial institutions to maintain procedures to identify and verify beneficial owners of legal entity customers, including individuals with 25 percent or more equity ownership and one control person, with recordkeeping requirements. An agent can collect documents, compare names, flag gaps, and prepare the file. It should not silently decide that an unresolved ownership question is fine.

This is also an AI risk control. The NIST Generative AI Profile calls out risks such as sensitive data exposure, human-AI configuration, information integrity, and provenance. It recommends documenting content provenance, measuring performance under deployment-like conditions, monitoring sensitive data exposure, and connecting AI policies to existing data, software, IT, legal, compliance, and risk activities. That is not an abstract governance exercise. It is the checklist for making finance agents reviewable.

The Security Problem Hiding in Document Review

Multi-document agents need access to sensitive material: payroll, tax IDs, bank details, contracts, customer files, employee records, and internal approvals. That makes least privilege and output control part of the workflow, not a separate security project.

OWASP's Top 10 for LLM Applications 2025 is a useful checklist here because finance agents touch several risk categories at once: prompt injection, sensitive information disclosure, supply chain risk, improper output handling, excessive agency, vector and embedding weaknesses, and misinformation. A malicious instruction can be hidden in a vendor PDF. A retrieved contract can contain confidential pricing. A tool with too much authority can update a vendor record instead of drafting a change request.

The answer is boring, which is good:

• Read-only access by default.
• Separate tools for draft, request, approve, and execute.
• No payment release tool in the model loop unless the workflow is narrow and tested.
• Redaction for unnecessary sensitive fields.
• Source citations required for every finding.
• Immutable logs for packet assembly, tool calls, checks, approvals, and final action.
• Sandboxed eval cases before production rollout.

OpenNash has written about this same control layer in AI agent audit trails for regulated industries and turning production failures into eval cases. Finance and compliance work makes those practices non-optional. If the agent misses a duplicate vendor or routes a false approval, that failure should become a named test case before the next release.

Start With One Packet

The first project should be one recurring packet, not "automate compliance."

Pick a workflow with volume, pain, and clear evidence. Three-way match exceptions are often a strong starting point. Vendor onboarding is another. Expense audits work well when policies are written down. Month-end accrual support is useful when the current process depends on email archaeology and spreadsheet screenshots.

Then build the operating loop:

1. Map the packet. List every document, system, owner, and required field.
2. Define pass criteria. State what must be true for auto-clear, exception, escalation, and rejection.
3. Create the golden set. Pull 50 to 100 historical cases: clean approvals, missing evidence, policy exceptions, fraud-like patterns, and messy edge cases.
4. Separate rules from judgment. Totals, thresholds, due dates, required fields, duplicate checks, and approval limits belong in code. Clause interpretation and exception notes can use models.
5. Run shadow mode. Let the agent review packets without taking action. Compare its queue against human reviewers.
6. Install approval gates. Decide which findings require AP, controller, legal, compliance, or executive review.
7. Measure outcomes. Track cycle time, exception rate, false clears, false escalations, missing evidence, reviewer override rate, and audit log completeness.
8. Promote narrow paths. Only after shadow results are strong should low-risk auto-clear or auto-request paths go live.

This is the same pattern as workflow-specific evals: the agent should be judged against your real cases, your rules, and your risk tolerance. Generic model benchmarks do not tell you whether the system will catch a payment term mismatch in your ERP.

Where OpenNash Fits

OpenNash builds these systems as owned workflow infrastructure, not one-off prompt projects.

For a finance or compliance team, that usually means:

• Auditing the current packet flow, systems of record, approval paths, and exception queues.
• Designing the agent workflow with deterministic checks, document extraction, entity matching, routing, and human approval points.
• Building the integrations into ERP, AP, payroll, contract, ticketing, data room, and storage systems.
• Creating the eval set from historical packets and production failures.
• Implementing trace logs and dashboards that operators, auditors, and executives can inspect.
• Handing over the code, prompts, policies, evals, and operating docs.

The business case is not "AI reads PDFs faster." That is too small. The point is tighter working capital controls, shorter review cycles, fewer missed exceptions, cleaner audit support, and a compliance function that can scale without turning every transaction into manual detective work.

The first safe win is usually not full automation. It is a reviewed exception queue that is better assembled than any human would have time to prepare.

If your controllers, AP leads, or compliance owners are still rebuilding the same packet by hand every week, start there. Pick the queue, capture the evidence, write the checks, and make the agent prove it knows when to stop.