Enterprise Financial Audit Agent System Design: From Invoice OCR to Compliance Closure

This article is based on a real-world interview scenario shared by a Bilibili creator. The original question was: Design a fully automated expense reimbursement and financial audit Agent for enterprise internal use — one that integrates with ERP interfaces, handles invoice OCR, and auto-generates compliance reports.

What makes this question challenging is that it doesn't test any single model in isolation. It tests whether you can wire together multimodal recognition, Agent orchestration, ERP integration, and audit rules into a system that actually runs in production. The core idea can be distilled into one phrase: from document recognition to compliance closure — invoices, policies, budgets, and accounting all handled by Agents that read, audit, and log automatically.

Why Enterprises Need a Financial Audit Agent

Before jumping into the design, it's worth understanding the real pain points. Step into the shoes of a finance director, and three problems stand out:

First, documents come from everywhere. Fully digitized tax invoices, e-invoices, PDFs, and phone-snapped receipts — formats and quality vary wildly, and manual sorting is prohibitively expensive.

Second, manual review is exhausting. Finance teams spend every day cross-checking expense policies, verifying invoice authenticity, and validating budget balances — all highly repetitive mechanical work.

Third, compliance risks are hidden. Duplicate reimbursements, over-limit claims, and cross-period entries aren't obvious at a glance — they're buried in operational details.

The essence of solving this problem comes down to one sentence: upgrade spot-checking to systematic verification, intelligent judgment, and tiered handling. That word "tiered" is the soul of this entire system — you'll see it come up again and again.

Understand the Business Flow Before Choosing Technology

Many candidates jump straight to discussing model selection. That's the wrong order. The core business flow is actually just four clear steps:

1. Employee submits documents
2. System parses the invoices
3. Compliance checks are run
4. Results are posted to ERP and logged for audit

The pipeline itself isn't complicated, but one hard requirement runs through every step: everything must be traceable. Who submitted what, what was verified, which rule was applied, which voucher was generated — all of it must be queryable.

This "traceable closed loop" is the lifeline of the entire solution. Every architectural decision that follows exists to serve this principle.

Layered Collaborative Architecture: Master Audit Agent and Specialized Capability Layer

How should the system be organized? This is a critical architecture question. Never design this as a chat interface — that approach simply doesn't hold up in financial operations.

The right approach is a collaborative system with distinct layers:

The Core: Master Audit Agent

This Agent doesn't do the grunt work itself. Its responsibilities are planning tasks, invoking tools, aggregating evidence, managing workflow state, and routing by risk level. Think of it as a project manager.

Left Side: Business Ingestion Layer

Employee expense reports, e-invoices from email, corporate travel data, ERP systems, and budget systems all flow in through this layer.

Right Side: Specialized Capability Layer

This includes invoice OCR and document understanding, tax invoice authenticity verification, rule and policy auditing, and voucher generation and archiving. The master Agent delegates to these capability modules and aggregates their outputs into a final conclusion.

The biggest benefit of this layered approach is decoupling: you can swap models without touching the architecture, replace ERP systems without affecting upper layers, and evolve each layer independently. This is exactly the engineering mindset interviewers want to see.

Invoice Parsing: Four Channels, Each with a Role

Go one level deeper and you reach a detail interviewers love to probe: how does invoice OCR parsing actually work? The core principle is: read the document accurately first, then make business judgments. This is done across four channels:

Channel 1: Direct Structured Read

Modern fully digitized tax invoices come in XML or OFD formats — the data is already structured. You can read it directly. Why make a model interpret an image when you don't have to? This path has the lowest inherent error rate and should always be the first choice.

Channel 2: Multimodal Understanding

For scanned documents, photos, or complex layouts, hand them to a Vision-Language Model (VLM) to extract fields and semantics directly from the page.

Channel 3: Authoritative Interface Verification

Whether an invoice is genuine, voided, or reversed must be verified against authoritative data sources. Note: the model has no responsibility for authenticity judgment — it doesn't have that capability, and you shouldn't expect it to.

Channel 4: Multi-Dimensional Deduplication

Combine invoice numbers, amounts, dates, personnel, and vendor dimensions to match against existing records and identify duplicate reimbursements or suspicious correlations.

Additionally, critical fields like amounts, tax IDs, and dates should undergo multi-path reconciliation — any discrepancy triggers a downgrade to manual review. These four steps together constitute what it truly means to "read correctly and verify authentically."

Compliance Auditing: The Dual-Engine Architecture Is the Decisive Factor

Once invoices are parsed, the main event begins. The compliance audit stage is the critical differentiator of this entire problem.

Many candidates hear "compliance" and say: just feed the reimbursement policy to an LLM and have it read through — done. That answer will cost you points. The correct answer is a dual-engine architecture.

Hard Rules Engine: Enforcing Deterministic Red Lines

Whether an expense exceeds the policy limit, whether the budget is exhausted, whether approvals are missing, whether invoice headers, dates, and categories are correct, whether debits and credits balance — all of these must go through the rules engine. The reason is simple: zero missed violations, full explainability, and when something is blocked, the system can tell you exactly which clause of which rule was violated.

A critical detail here: enterprise policies must be pre-compiled into rules, not interpreted by a model on the fly each time. Only this guarantees consistent judgments.

Semantic Audit Engine: Evaluating Business Substance

Does the stated purpose of a business trip actually match the submitted receipts? Is a single trip being split across multiple invoices? Is the relationship between a vendor and an itinerary reasonable? How should novel scenarios not covered by existing policy be handled? These soft judgments belong to the LLM — it excels at understanding context and handling long-tail edge cases.

Fusion and Tiered Routing

The outputs of both engines are fused and used for risk tiering, with three routing outcomes:

• Low risk → Auto-approve
• Flagged → Route to human review
• Red line hit → Auto-reject

Remember this principle: deterministic checks belong to rules, semantic checks belong to models, and edge cases belong to humans. One more mindset worth stating explicitly: no matter how high your automation rate climbs, the rate of missed red-line violations always matters more than the approval rate.

ERP Write-Back: Agents Acting Within Boundaries

Once an audit passes, results must be written to the ERP — this is where Agents actually "do work," and also where things most easily go wrong. One principle governs everything: Agents can act, but must act within defined boundaries.

Read Before Write

The front-end business data includes expense reports, approvals, invoices, budgets, and account codes. The Agent must read facts first, then generate proposals — always read before writing, never act blindly.

Unified ERP Adapter

Place a unified ERP adapter in the middle layer. Whether the backend is SAP, Yonyou, or Kingdee, all interactions go through this adapter. Agents never touch each vendor's proprietary protocol directly — this ensures maintainability and reduces risk.

Five Accounting Safety Guardrails

1. Idempotency keys: Prevent duplicate writes
2. Staging area first: Only post to the ledger after validation passes
3. Debit-credit balance deterministic check: Anomalies trigger reversals with rollback support
4. Full audit logging: Every action is auditable
5. Rollback mechanism: Exceptions can be undone

If you can articulate these five guardrails clearly in an interview, the interviewer will know you've genuinely thought through production deployment — not just theorizing on paper.

Final Deliverable: A Traceable Compliance Report

What this system ultimately delivers is not a cold "Approved / Rejected" verdict, but a complete compliance report containing:

• Invoice authenticity verification results
• Expense policy and budget compliance status
• Business relevance analysis
• A traceable audit evidence chain

Every risk flag in the report links back to the original source documents. Humans and the system look at the same chain of evidence.

To summarize the entire solution in three sentences:

Deterministic problems go to rules and interfaces. Semantic and irregular problems go to multimodal models. High-risk actions go through process guardrails.

Get these three things right, and what you're delivering to the finance team isn't just a chatty tool — it's a system that genuinely frees them from repetitive reconciliation work, so they can redirect their energy back to judgment and business operations. That's what a financial audit Agent should truly look like.