AGENTS.md Template for Finance Reconciliation Agents
AGENTS.md Template for Finance Reconciliation Agents—formal operating manual for single-agent and multi-agent orchestration in finance reconciliation workflows.
Target User
Developers, founders, product teams, engineering leaders
Use Cases
- Automated transaction reconciliation across ERP and GL systems
- Vendor and customer payment matching
- Audit-ready reconciliation trails
- Discrepancy triage with escalation to compliance or finance team
Markdown Template
AGENTS.md Template for Finance Reconciliation Agents
# AGENTS.md
Project role
- Led by Finance Reconciliation Automation Owner. The project aims to produce auditable, repeatable bank, vendor, and customer reconciliation across ERP/GL systems with agent handoffs and human review as needed.
Agent roster and responsibilities
- Planner: designs reconciliation plan, data mappings, rules, and escalation thresholds.
- Implementer: fetches source data (ERP GL, bank feeds, sub-ledgers), applies transformations, and prepares reconciled datasets.
- Validator: enforces data quality, rule compliance, and discrepancy detection.
- Reviewer: audits results, signs off final reconciliations, and ensures regulatory alignment.
- Domain Specialist: provides domain-specific knowledge (ERP modules, chart of accounts, bank file formats).
Supervisor or orchestrator behavior
- Orchestrator maintains the single source of truth, memory of decisions, and a living log of actions.
- Coordinates handoffs with explicit signals (e.g., "Discrepancy Detected" or "Ready for Validation").
- Enforces timeouts, retries, and escalation to human review when thresholds are exceeded.
Handoff rules between agents
- Planner → Implementer: handoff plan, data sources, and mapping rules.
- Implementer → Validator: handoff prepared dataset and rule results for quality checks.
- Validator → Reviewer: handoff final reconciled subset with justification notes.
- Domain Specialist → Planner: provide domain input to refine rules and mappings.
Context, memory, and source-of-truth rules
- All decisions are logged with timestamps, agent identities, and justifications.
- The canonical source of truth is the reconciled ledger dataset stored in the data lake with a verifiable hash.
- Source-of-truth mappings must reference the original data sources (ERP extracts, bank feeds) with lineage.
Tool access and permission rules
- Implementer may read source data and write to a staging area.
- Validator may run quality checks and validation scripts.
- No agent may modify the live production ledger directly without approval gates.
- Secrets and credentials are accessed via a secure vault and never embedded in code.
Architecture rules
- Use modular components: data connectors, transformation layer, reconciliation engine, audit trail.
- All external service calls are logged and rate-limited.
File structure rules
- finance-reconciliation/
- AGENTS.md (this file)
- docs/
- src/
- planner/
- implementer/
- validator/
- reviewer/
- domain-specialist/
- tests/
- configs/
Data, API, or integration rules when relevant
- Data sources: ERP extracts, bank feeds, vendor master data.
- API calls must use secure endpoints with token-based auth and scoped permissions.
- All data transfers must be encrypted in transit and at rest where applicable.
Validation rules
- Rules include: amount match, date-range checks, currency consistency, and cross-ledger integrity.
- Reconciliations failing validation must trigger escalation to human review with justification.
Security rules
- Do not expose production credentials in logs or code.
- Secrets in vault; access controls by role; rotate keys periodically.
Testing rules
- Unit tests for each rule; integration tests across data sources; end-to-end reconciliation tests with synthetic data.
Deployment rules
- Deploy agents and rules to a staging environment first; run automated tests; monitor for drift before production.
Human review and escalation rules
- If discrepancies exceed thresholds or confidence is low, escalate to Finance Compliance or Controller.
- Provide auditable rationale and data lineage for each escalation.
Failure handling and rollback rules
- On failure, revert to last good reconciliation point and rollback staging changes.
- Notify stakeholders and trigger a retrial workflow.
Things Agents must not do
- Do not modify production data without explicit approval gates.
- Do not bypass validation when discrepancies are detected.
- Do not store secrets in code repositories.Overview
The AGENTS.md Template for Finance Reconciliation Agents formalizes the operating context for single-agent and multi-agent reconciliation workflows. It defines the agent roster, handoffs, context rules, tool access, and governance needed to reconcile financial data across systems with auditable memory and source-of-truth alignment. Directly usable as a project-level operating manual for AI coding agents in finance workflows.
When to Use This AGENTS.md Template
- When automating cross-system reconciliations (ERP, GL, bank feeds, payables/receivables).
- When multiple agents must collaborate to map, fetch, validate, match, and finalize reconciliations.
- When formal guardrails, auditability, and escalation to human review are required.
- When you need a repeatable template to bootstrap new reconciliation workflows with agent handoffs and governance.
Copyable AGENTS.md Template
Copy the block below into a file named AGENTS.md in the repository root of your finance reconciliation project. It establishes the operating context for the agent workflow and multi-agent coordination.
# AGENTS.md
Project role
- Led by Finance Reconciliation Automation Owner. The project aims to produce auditable, repeatable bank, vendor, and customer reconciliation across ERP/GL systems with agent handoffs and human review as needed.
Agent roster and responsibilities
- Planner: designs reconciliation plan, data mappings, rules, and escalation thresholds.
- Implementer: fetches source data (ERP GL, bank feeds, sub-ledgers), applies transformations, and prepares reconciled datasets.
- Validator: enforces data quality, rule compliance, and discrepancy detection.
- Reviewer: audits results, signs off final reconciliations, and ensures regulatory alignment.
- Domain Specialist: provides domain-specific knowledge (ERP modules, chart of accounts, bank file formats).
Supervisor or orchestrator behavior
- Orchestrator maintains the single source of truth, memory of decisions, and a living log of actions.
- Coordinates handoffs with explicit signals (e.g., "Discrepancy Detected" or "Ready for Validation").
- Enforces timeouts, retries, and escalation to human review when thresholds are exceeded.
Handoff rules between agents
- Planner → Implementer: handoff plan, data sources, and mapping rules.
- Implementer → Validator: handoff prepared dataset and rule results for quality checks.
- Validator → Reviewer: handoff final reconciled subset with justification notes.
- Domain Specialist → Planner: provide domain input to refine rules and mappings.
Context, memory, and source-of-truth rules
- All decisions are logged with timestamps, agent identities, and justifications.
- The canonical source of truth is the reconciled ledger dataset stored in the data lake with a verifiable hash.
- Source-of-truth mappings must reference the original data sources (ERP extracts, bank feeds) with lineage.
Tool access and permission rules
- Implementer may read source data and write to a staging area.
- Validator may run quality checks and validation scripts.
- No agent may modify the live production ledger directly without approval gates.
- Secrets and credentials are accessed via a secure vault and never embedded in code.
Architecture rules
- Use modular components: data connectors, transformation layer, reconciliation engine, audit trail.
- All external service calls are logged and rate-limited.
File structure rules
- finance-reconciliation/
- AGENTS.md (this file)
- docs/
- src/
- planner/
- implementer/
- validator/
- reviewer/
- domain-specialist/
- tests/
- configs/
Data, API, or integration rules when relevant
- Data sources: ERP extracts, bank feeds, vendor master data.
- API calls must use secure endpoints with token-based auth and scoped permissions.
- All data transfers must be encrypted in transit and at rest where applicable.
Validation rules
- Rules include: amount match, date-range checks, currency consistency, and cross-ledger integrity.
- Reconciliations failing validation must trigger escalation to human review with justification.
Security rules
- Do not expose production credentials in logs or code.
- Secrets in vault; access controls by role; rotate keys periodically.
Testing rules
- Unit tests for each rule; integration tests across data sources; end-to-end reconciliation tests with synthetic data.
Deployment rules
- Deploy agents and rules to a staging environment first; run automated tests; monitor for drift before production.
Human review and escalation rules
- If discrepancies exceed thresholds or confidence is low, escalate to Finance Compliance or Controller.
- Provide auditable rationale and data lineage for each escalation.
Failure handling and rollback rules
- On failure, revert to last good reconciliation point and rollback staging changes.
- Notify stakeholders and trigger a retrial workflow.
Things Agents must not do
- Do not modify production data without explicit approval gates.
- Do not bypass validation when discrepancies are detected.
- Do not store secrets in code repositories.
Recommended Agent Operating Model
Roles, responsibilities, decision boundaries, and escalation paths are defined to support both single-agent and multi-agent reconciliation workflows. The Planner designs the plan; the Implementer executes data retrieval and preparation; the Validator enforces data quality; the Reviewer signs off; the Domain Specialist injects domain knowledge. Escalation paths move from automated checks to human review as thresholds are breached.
Recommended Project Structure
finance-reconciliation/
├── AGENTS.md
├── docs/
├── src/
│ ├── planner/
│ ├── implementer/
│ ├── validator/
│ ├── reviewer/
│ └── domain-specialist/
├── tests/
└── configs/
Core Operating Principles
- Single source of truth with verifiable data lineage.
- Explicit agent handoffs and decision boundaries.
- Auditability, memory, and versioned results for all reconciliations.
- Secure access controls and secrets management.
- Escalation to human review for critical discrepancies.
Agent Handoff and Collaboration Rules
Planner plans and communicates the reconciliation strategy to Implementer. Implementer fetches data and applies transformations, then passes to Validator. Validator checks quality and passes to Reviewer. Domain Specialist can intervene at any stage to adjust rules or mappings and re-train agents as needed. Clear, time-bound handoffs with explicit signals are required at every step.
Tool Governance and Permission Rules
- All tool calls are authenticated and audited.
- Unless approved, no agent may alter live production data sources.
- Secrets must be retrieved from a secure vault; never embedded in code.
- Production deployments require staged validation and sign-off from a human in finance governance.
Code Construction Rules
- Write idempotent, auditable code with deterministic outputs.
- Separate data access, business logic, and presentation concerns.
- Document state transitions and decision rationales inline in AGENTS.md comments.
Security and Production Rules
- Encrypt data in transit and at rest; rotate keys regularly.
- Limit access by role; implement least-privilege principles.
- Log all actions; retain logs for regulatory review.
Testing Checklist
- Unit tests for each rule and data transformation.
- Integration tests across ERP, bank feeds, and GL systems.
- End-to-end tests with synthetic data and audit trails.
- Rollout tests in staging before production deployment.
Common Mistakes to Avoid
- Overloading bots with production schema without mappings or data lineage.
- Skipping validation checks or bypassing handoffs.
- Storing credentials in code or logs.
- Unclear escalation paths or missing audit trails.
FAQ
What is the purpose of this AGENTS.md Template for finance reconciliation?
It provides a formal operating manual and plays the role of a project-level context for single-agent and multi-agent reconciliation workflows, ensuring governance and auditable handoffs.
Which roles are included in the agent roster for reconciliation?
Planner, Implementer, Validator, Reviewer, and Domain Specialist, with an optional Auditor for traceability.
How are handoffs between agents managed?
Handoffs use explicit signals, truth pointers, and time-bound steps to ensure memory, context, and justification travel with the work item.
What security measures govern this workflow?
Access is role-based, secrets live in a vault, data is encrypted in transit and at rest, and production actions require approval gates.
How is validation and testing enforced?
Validation rules enforce data quality; testing includes unit, integration, and end-to-end tests in staging before production.