For finance teams

Put an AI agent in your close cycle. Keep the controls.

A plain-English explainer for controllers, FP&A leads, and accounting managers piloting AI in close, reconciliation, or AP — without giving up the controls your auditor depends on.

Your team can recognize 95% of GL ↔ subledger matches in seconds. The remaining 5% — the exceptions, the above-materiality cases, the cross-entity intercompany clearing that needs FX commentary — is where your time goes. closegate is the layer that lets the AI agent safely handle the 95% so your team owns the 5% with judgment.

What changes after closegate

Today (manual)Vendor "agentic" black boxclosegate
Controller ties out GL/SL line-by-line in spreadsheetsAgent auto-matches; you trust vendor's RCA if something breaksAgent proposes matches; policy gate auto-confirms below materiality, routes above to your HITL inbox
Above-materiality match → controller manually escalatesAbove-materiality match → vendor decides routing internallyAbove-materiality match → server-side rule fires, your named approver gets a Slack/Teams card with the verbatim policy clause
Audit prep = 2 weeks of spreadsheet screenshotsAudit prep = vendor PBC bundle (their format, their definitions)Audit prep = closegate-engine audit-evidence-export → one ZIP with the SQL audit log, actor identities, and policy versions
You can't reproduce what happened in close 3 months agoYou can ask the vendor; they'll get back to yougit log on policy.yaml + replay the audit log — anyone with the data can reconstruct any decision
Fraud risk = manual vigilanceFraud risk = vendor's threat model (closed)Fraud risk = sensitive-account routing forces HITL on cash, legal accruals, vendor bank changes, regardless of materiality

The four pieces, in finance-team language

1. Policy gate — the chokepoint

Every state-changing action (confirm match, approve invoice, submit payment run) passes through one transactional gate. The gate decides: Allow (mutate + write audit), RequireHumanApproval (route to HITL inbox), or Deny (write violation event, raise to controller). There is no second confirmation API anywhere in the system.

2. Audit log — the auditor's friend

Append-only SQLite table. BEFORE UPDATE and BEFORE DELETE triggers refuse the operation at the database layer — not in application code, so an insider with code-write access can't quietly tamper. Every blocked event carries the verbatim policy clause text (auditors quote it verbatim) and a JSON-pointer to your policy.yaml source.

3. HITL approval inbox — your queue, not the vendor's

When the gate routes a state-change to HITL, the approval lands in a web inbox + a Slack/Teams card with deeplink-back to the canonical web record. The approver confirms via a different actor identity; the gate enforces SoD server-side. The LLM cannot impersonate a human approver, no matter what the chat history says.

4. Eval harness — your audit committee's friend

Four dimensions run continuously: matching accuracy, policy enforcement, adversarial robustness, latency. Output is a reproducible JSON artifact your audit committee can read. Pairs with the soc2-monitor nightly CI job so you have SOC 2 CC4.2 evidence on autopilot.

Is closegate right for our team?

Strong fit:

  • You're piloting an AI agent against close, recon, or AP and your internal auditor is the bottleneck
  • You self-host or want to (Docker, Kubernetes, fly.io)
  • You're scoping a SOC 2 Type 2 readiness program and want operational evidence on autopilot
  • You're multi-entity / multi-jurisdiction and need per-entity materiality overrides
  • You've been quoted $100K+/yr for a vendor and want to evaluate the open alternative

Probably not the right call yet:

  • You haven't done a manual close in 2026 — start with the workflow before adding the agent
  • You want a turnkey SaaS UI with white-glove onboarding for non-technical staff — closegate is a reference architecture, not a managed product
  • Your policy.yaml shape is "we'll figure it out as we go" — closegate works best with explicit materiality + SoD rules

What a pilot looks like

  1. Week 1: Clone the repo, run the SaaS seed pack locally, walk your CFO through the workspace UI. (Tutorial: install in 60 seconds.)
  2. Week 2–4: Port your existing policy thresholds to policy.yaml. Test against the 11 starter jurisdictional libraries.
  3. Week 5–8: Wire a real ingestion adapter (Stripe, QuickBooks, NetSuite, etc.). Run the deterministic eval against your data.
  4. Week 9–12: Parallel-run alongside your existing close for one full cycle. Compare outputs. Surface the deltas to internal audit.

The 30/60/90 pilot plan with stakeholder briefings, control-mapping walkthroughs, and a security review template lives in the technical docs. The CFO pitch deck and ROI calculator live on this site — For CFOs and ROI.

Inbound

Talk to the maintainer

Two design-partner slots open this quarter. One real workflow, your real policy.yaml, monthly 30-min call, direct line. Apache-2.0, self-hosted, no seat licensing — forever.