From $0 to $250K: Spending Tier Policies That Actually Enforce Themselves

Category: Financial Services | Reading time: 5 min

---

The Approval Matrix Nobody Follows

Every finance team has one. A spreadsheet, a policy document, maybe a Confluence page: "Payments under $1,000 — AP clerk. $1,000–$25,000 — manager approval. $25,000–$250,000 — VP Finance. Over $250,000 — CFO."

In practice, it's a suggestion. Someone is on holiday, so the CFO approval "can wait until Monday." A manager bulk-approves a queue without reviewing individual amounts. An AP clerk finds a workaround to split a $30,000 invoice into three smaller ones. The policy exists on paper. Enforcement is inconsistent.

When an AI agent takes over payment processing, inconsistent enforcement becomes a risk you can no longer explain away. The agent will either enforce the policy correctly every time — or it won't. There's no nuance, no judgment call, no "I'll flag this for review." You need the approval matrix to actually work.

---

Encoding the Matrix as Policy

Taos translates spending tier rules into Rego — deterministic, evaluable, auditable:

package taos.paymentpilot.vendor_payment

# Tier 1: Auto-approve (< $1,000)
tier_auto_approve {
    input.amount >= 0
    input.amount < 1000
    input.vendor_status == "approved"
    input.is_ofac_cleared == true
}

# Tier 2: Manager approval ($1,000 – $25,000)
tier_manager_approval {
    input.amount >= 1000
    input.amount < 25000
    input.vendor_status == "approved"
    input.is_ofac_cleared == true
}

# Tier 3: VP Finance ($25,000 – $250,000)
tier_vp_finance_approval {
    input.amount >= 25000
    input.amount < 250000
    input.vendor_status == "approved"
    input.is_ofac_cleared == true
}

# Tier 4: CFO (≥ $250,000)
tier_cfo_approval {
    input.amount >= 250000
    input.vendor_status == "approved"
    input.is_ofac_cleared == true
}

# Required approver role for each tier
required_role = "manager"    { tier_manager_approval }
required_role = "vp_finance" { tier_vp_finance_approval }
required_role = "cfo"        { tier_cfo_approval }

This isn't an if-else chain in application code. It's a policy document that the governance kernel evaluates at runtime. The application code doesn't know about thresholds — it only knows whether policy returned allow, require_approval, or deny.

---

Authority Levels: No Self-Approval Above Your Tier

The second half of the problem is who can approve what. A manager shouldn't be able to approve their own $200,000 payment. A VP Finance shouldn't be able to unilaterally approve a CFO-tier payment.

Taos encodes authority levels as a role hierarchy:

Role	Authority level	Can approve
AP Clerk	0	Nothing (submit only)
Manager	1	Manager tier (< $25K)
VP Finance	2	Manager + VP Finance tier (< $250K)
CFO	3	All tiers

When a payment request arrives, the kernel:

1. Evaluates the Rego policy → determines required_role
2. Checks the submitter's role against the authority matrix
3. If the submitter has sufficient authority — auto-approved with OBO chain recorded
4. If the submitter does not — raises ApprovalPendingError → routes to the correct approver

An AP clerk submitting a $500 payment gets it auto-approved. An AP clerk submitting a $30,000 payment gets routed to a manager. A manager submitting a $30,000 payment approves it themselves. A manager submitting a $100,000 payment gets routed to VP Finance. This is not configurable at the application layer — it's enforced at the kernel layer.

---

The Invoice-Splitting Problem: Solved

What about the classic workaround — splitting a $30,000 invoice into three $9,999 invoices to stay under the manager threshold?

With Taos, each invoice is evaluated independently against the policy. However, you can add an aggregate rule:

# Deny if vendor total in current period exceeds auto-approve threshold
deny_aggregate_threshold {
    input.vendor_period_total >= 25000
    input.amount >= 1000
}

The vendor_period_total is computed before policy evaluation and passed as an input attribute. The split-invoice workaround hits the aggregate rule and gets routed to manager approval anyway.

The rule lives in the policy bundle. Finance updates it — not engineering.

---

Changing Thresholds Without Changing Code

In Q4, your CFO decides to lower the auto-approve threshold from $1,000 to $500 due to a budget crunch. In a traditional system, this means:

• Engineering ticket
• Code change
• Test suite update
• Deployment

In Taos:

1. Finance manager opens the Policy Bundles page in the control plane
2. Edits the tier_auto_approve rule: input.amount < 1000 → input.amount < 500
3. Publishes the new version
4. The kernel picks it up on the next evaluation — no restart, no deployment

The change is versioned, timestamped, attributed to the person who made it, and auditable. If the CFO wants to revert in January, that's another two-minute policy edit.

---

What the Approval Queue Looks Like

When a payment requires approval, the agent pauses and creates an approval request:

{
  "approval_id": "appr-abc123",
  "invoice_id": "INV-7821",
  "amount": 18500.00,
  "vendor_name": "Acme Supplies Ltd",
  "required_role": "manager",
  "submitted_by": "aclerk",
  "policy_rule": "tier_manager_approval",
  "nonce": "f3a2b1c4"
}

The manager sees this in the approval queue, reviews it, and approves or rejects. The approval is signed, the OBO chain is extended, and the workflow resumes — or compensates if rejected.

---

The Bottom Line

Spending tier policies aren't hard to write. They're hard to enforce consistently across thousands of payments, multiple agents, and changing business conditions.

Policy-as-code makes the approval matrix a first-class technical artifact — something that runs deterministically, can be changed without engineering, and produces an auditable record of every decision. Your approval matrix stops being a Confluence page and starts being an enforceable control.

---

Tags: spending tiers, AP approval workflow, policy-as-code, financial controls, AI governance, accounts payable