What materiality threshold should we set for the AI pilot?

Conservative for the first cycle. A typical Series A SaaS finance team starts at $5K; mid-market at $25K; enterprise at $50K–$100K. The right answer is one materiality scale below what your manual controls already use, so the agent never has more authority than a controller working alone. Raise the threshold slowly across cycles as the audit-event distribution stays clean.

How do per-entity materiality overrides work?

Each entity carries its own threshold. US parent might be $10K; JP sub ¥1M; IN sub ₹500K. The gate looks up the override based on the match's entity_id. Without overrides, every entity uses the global threshold — which doesn't work for multi-jurisdiction holdcos.

What's the difference between materiality and sensitive-account routing?

Materiality is about size — above $X, the action requires HITL. Sensitive-account routing is about category — touching cash, legal accruals, or vendor bank-change events requires HITL regardless of size. Both fire independently; either one can route to HITL.

Deep dive

Materiality thresholds for AI: what's defensible to your audit committee

Setting materiality thresholds for AI agent actions is harder than picking a number. Here's how to think about per-entity overrides, sensitive-account routing, and the audit-committee narrative.

Dipankar Sarkar June 12, 2026 5 min read

materiality AI agents SOX audit committee policy

Setting materiality thresholds for AI agent actions is one of the questions design partners get wrong first. The temptation is to pick a number that sounds defensible (“$50K, like our internal control matrix”) and move on. The reality is more nuanced: the threshold has to defend against a different threat model than your manual controls do.

This article walks the three knobs (global threshold, per-entity overrides, sensitive-account routing) and how to set each.

Why AI materiality is different from manual materiality

Your manual control matrix probably has a tier structure:

Below $1K: any controller can confirm
$1K–$10K: senior controller confirms
$10K–$50K: controller + AP manager dual-sign
Above $50K: CFO sign-off required

That works for humans because the human has judgment. A controller looking at a $10K match notices the vendor name, the description, the timing. They can override the formal threshold with informal judgment (“this is a recurring AWS bill; obviously fine”) or escalate when something feels off (“the vendor name changed last month; want to double-check”).

AI agents don’t have that judgment, at least not reliably. The agent looks at the structured fields, runs the matcher, and proposes. So the materiality threshold needs to be more conservative than the human one, because:

No informal escalation. The agent won’t notice a vendor name oddity unless it’s in the matcher’s feature set.
No accumulated context. The agent doesn’t remember last quarter’s audit-committee complaint about a specific account.
No batched judgment. A human reviewing 50 matches notices patterns; the agent reviews each one in isolation.

The fix isn’t to make the agent smarter; it’s to set materiality conservatively and let HITL pick up the cases that need judgment.

The global threshold

Start here. One number, applied to every match where no per-entity override fires.

Reasonable starting points by team size:

Team shape	Pilot threshold	Steady-state threshold
Series A B2B SaaS (5 FTEs)	$5K	$10K
Mid-market SaaS (15 FTEs)	$15K	$25K
Pre-IPO / public company	$25K	$50K
Enterprise multi-entity	$50K	$100K+

The pilot threshold is what you set in week 1; the steady-state is what you might be at after 6 months of clean audit-event distribution. Raise slowly. Watch the HITL queue volume.

Per-entity materiality overrides

For multi-entity / multi-jurisdiction operations, a global threshold doesn’t work. A $10K threshold makes sense for a US parent but is wrong for a JP sub (¥1M is the conventional equivalent; ¥10K is ~$66 — way too tight) and wrong for an IN sub (₹500K ≈ $6K is closer to local norm).

closegate’s entity_materiality_overrides field is the answer:

materiality_threshold_usd: 10000

entity_materiality_overrides:
  us-parent: 10000      # USD
  uk-sub: 8000          # GBP — set in local currency, converted at gate-time
  jp-sub: 1000000       # JPY
  in-sub: 500000        # INR
  de-sub: 9000          # EUR

The gate uses the entity_id from the match’s GL/SL entry to look up the override. The FX conversion happens via the configured FxRateAdapter (fixed, ECB daily, OpenExchangeRates, or your in-house feed).

This is one of the things the commercial vendors handle via professional services engagement. closegate ships it as a config field; you set it in your policy.yaml.

Sensitive-account routing

Materiality is about size. Sensitive accounts are about category. Some accounts route to HITL regardless of how small the transaction:

Cash accounts — any movement, even $1, gets reviewed. Fraud risk.
Legal accruals — high audit-committee scrutiny; tone matters.
Intercompany clearing — easy to post to the wrong entity; cross-entity hygiene matters.
Vendor bank-change events — the canonical fraud vector (the 2:14am attack). Always HITL.
Tax provisions — quarter-end + year-end attention.
Suspense accounts — by definition unresolved; needs human eyes.

In closegate’s policy.yaml:

always_human_accounts:
  - "1000"              # cash
  - "1010-OPERATING"
  - "1020-PAYROLL"
  - "2000-LEGAL"        # legal accruals
  - "2100-TAX"          # tax provisions
  - "1500-INTERCO"      # intercompany clearing receivable
  - "2500-INTERCO"      # intercompany clearing payable
  - "9999-SUSPENSE"     # suspense
  - "VENDOR_BANK"       # vendor bank-change event type

The gate fires HITL on any action touching any of these, regardless of materiality. Sensitive-account routing is the “if in doubt, ask the human” knob.

Sensitive match types

Some match strategies should always be HITL even on below-materiality matches. closegate exposes this via no_auto_confirm_match_types:

no_auto_confirm_match_types:
  - "fuzzy_match"       # near-miss matches need a human even when small

The reason: fuzzy matches by definition have ambiguity. The deterministic exact + multi-to-one matchers don’t fire on ambiguous cases. The fuzzy matcher does, and its accuracy is good but not perfect. Routing all fuzzy matches to HITL is the conservative default.

What the audit committee wants to hear

The narrative for the audit committee, in three sentences:

Materiality threshold is $X, set conservatively for the AI pilot. Sample the audit-event distribution by amount; show that the threshold is being respected.
Sensitive accounts route to HITL regardless of amount. Sample the events for cash + legal + intercompany; show all of them have HITL routing.
Per-entity overrides handle multi-jurisdiction. Show the entity_materiality_overrides config + a sample event from the JP-sub showing HITL routed at ¥1M.

Pair with: the verbatim policy clause text on a sample MATERIALITY_OVER_THRESHOLD event, and the SoD chain on a sample HITL approval.

What to avoid

Don’t set the threshold higher than your manual matrix. The agent should never have more authority than your most-senior controller working alone.

Don’t fall for “the AI is conservative” hand-waving. Conservative materiality is enforced, not promised. Set the number; check the audit log.

Don’t skip sensitive-account routing. The $1K vendor bank-change event is the actual fraud vector. The $50K invoice from a known vendor isn’t.

Don’t allow runtime threshold changes from the agent. Materiality is policy.yaml; policy.yaml is git. Threshold changes require a PR with a controller’s review.

What this gives you

A defensible quantitative answer to “what is your materiality threshold?”
Per-entity flexibility for multi-jurisdiction operations
Server-side enforcement that can’t be overridden by an LLM or by application code
Audit-quotable clause text on every threshold-fired event