Back-office / accounting department playbook

This playbook illustrates how the agent blueprint applies to a department whose primary job is processing internal business events — invoices, approvals, reconciliations, expense submissions, and similar financial or administrative workflows. You might recognise this as an accounts payable function, a finance operations desk, or a general back-office coordination team. Use this as a reference when mapping the blueprint to your own equivalent department. Every placeholder (“Department C”, “VM-3”, “your ERP system”) stands in for the real names you would substitute during a scoping engagement.

This playbook describes a structural pattern, not a finished implementation. Exact scope, timelines, and fit for your situation are determined during the consulting process. See Scope & Boundaries for how scoping works.

Department profile

Dimension	Example value
Department name	Department C (back-office / accounting)
Primary role	Receive, validate, and route financial and administrative documents for human approval
Primary input sources	Your ERP system (new document events), shared invoice inbox, scheduled triggers
Primary outbound interfaces	Your ERP system (status updates), approval notification channel, audit log
VM designation	VM-3

Role definition

The agent’s role statement for a back-office department:

VM-3 is responsible for receiving financial and administrative documents, validating them against defined rules, and routing them to the correct approver with all relevant context pre-assembled. It does not approve, reject, or execute payments. All financial decisions require explicit human sign-off.

This constraint is non-negotiable for back-office agents. The agent prepares and routes; a person decides. The audit trail records both.

Standard operating procedures

SOP 1: Receive and validate a document

Trigger: A new document event arrives from a connected input source (e.g. a new invoice record in your ERP system, or a submission to the shared invoice inbox).Steps:

Extract the document fields: document type, reference number, amount, vendor or supplier identifier, and date.
Check whether the required fields are present and in the expected format.
Look up the corresponding purchase order or reference record in your ERP system.
Compare key fields (amount, vendor, line items if available) against the reference record.
Assign a validation status: matched, discrepancy found, or reference not found.
Log the validation result against the document record.
Route to SOP 2 (approval routing) with the validation result attached.

Escalation rule: If the document cannot be parsed or required fields are missing, route to the human review queue as “incomplete document” without attempting validation.

SOP 2: Route for approval

Trigger: Validated document with status from SOP 1.Steps:

Determine the correct approver based on the routing rules configured for this deployment (rules may be based on document type, amount range, department, or vendor category).
Compose an approval notification containing: document reference, amount, vendor, validation status, any discrepancy summary, and a link to the document record in your ERP system.
Send the notification to the approver via the configured channel (e.g. internal notification system or email).
Log the routing action with the approver identity and timestamp.
Set a follow-up reminder if no response is received within the configured window.

Escalation rule: If the approver cannot be determined from the routing rules, route to the human review queue flagged as “approver unknown”.

SOP 3: Process approval response

Trigger: An approval or rejection response is received from an approver.Steps:

Read the response and identify the decision: approved, rejected, or returned for clarification.
Update the document status in your ERP system to reflect the decision.
Log the decision with the approver identity, timestamp, and any comments provided.
If approved: mark the document as ready for payment processing (no payment is initiated by the agent).
If rejected: notify the relevant contact or team with the rejection reason.
If returned for clarification: route the document back to the human review queue with the clarification request attached.

Escalation rule: The agent never initiates a payment. “Ready for payment processing” is a status flag only — payment execution is always a manual step performed by an authorised person.

SOP 4: Generate periodic summary report

Trigger: Scheduled trigger (e.g. end of week, end of month — configured per deployment).Steps:

Query your ERP system for documents processed during the period: total received, matched, discrepancies found, pending approval, approved, rejected.
Compile the counts into a structured summary.
Format the summary using the approved report template.
Send the summary to the configured recipients.
Log the report generation event with a timestamp.

Note: The report contains counts and statuses only. It does not contain payment details or account balances.

Input sources

Input source	What it delivers	Format
Your ERP system	New document events (invoices, expense submissions, credit notes)	Structured JSON via webhook or polling
Shared invoice inbox	Supplier invoices received by email	Unstructured (PDF or email body)
Scheduled trigger	Periodic report generation, overdue follow-up reminders	Timer event

Outbound interfaces

Outbound interface	What the agent writes	Requires human approval?
Your ERP system	Document status updates, validation results, approval outcomes	No (status flags only)
Approval notification channel	Approval request messages with full context	N/A (routing only)
Audit log	Every action taken, with document reference, actor, and timestamp	No (append-only)
Human review queue	Incomplete documents, unknown approvers, discrepancies	N/A (routing only)

Escalation rules

The following situations always route to a human:

Document cannot be parsed or required fields are missing
Reference record (purchase order or equivalent) cannot be found in your ERP system
Discrepancy is found between the document and the reference record — these are never auto-approved
Approver cannot be determined from routing rules
Any document above the configured amount threshold (threshold is set per deployment)
Approval response contains a request for clarification

The agent has no ability to approve documents, initiate payments, or modify financial records beyond status flags. These constraints are enforced at the integration permission level, not just in the SOP logic.

JSON message flow (simplified)

A simplified document processing event written to the audit log:

{
  "event": "document_received",
  "source": "erp_webhook",
  "document_type": "invoice",
  "document_ref": "INV-2024-00891",
  "vendor_ref": "VENDOR-0015",
  "amount": 4200.00,
  "currency": "your_currency",
  "po_reference": "PO-2024-00214",
  "validation_status": "matched",
  "discrepancy": null,
  "routing_approver": "APPROVER-002",
  "notification_sent": true,
  "escalated": false,
  "timestamp": "2024-08-01T08:55:00Z"
}

For a document with a discrepancy, validation_status becomes "discrepancy_found", discrepancy contains a plain-language description, and escalated is true.

Audit trail

Every action the agent takes is written to an append-only audit log. Each entry records:

The input event that triggered the action
The SOP step executed
The data read and written
The human involved (if any — approver identity, reviewer identity)
A timestamp

This log is the primary record for any subsequent review or query about how a document was processed. It cannot be modified by the agent after writing.

Staged evolution

Phase	What is automated	What remains manual
Phase 1	Document receipt, parsing, and validation logging only	All routing and approval workflows
Phase 2	Approval routing notifications added	All approval decisions and ERP status updates
Phase 3	ERP status updates and periodic reports added	Payment execution (permanently manual)

Starting at Phase 1 lets the team validate the validation SOP against real documents before any notifications are sent to approvers. Discrepancy detection can be tuned during this phase with no risk of misdirecting approvals.

Cross-references

What is an agent? — role definitions and the three layers of every agent
Agent Structure → Overview — inputs, intelligence, and actions
Agent Structure → Components — guardrails, tools, and handoff rules
Agent Structure → Integrations — connecting ERP systems and approval channels
ERP & Legacy Systems — adapter patterns for connecting to existing financial systems
Scope & Boundaries — how scope and financial guardrails are defined and controlled

Get Started

Agent Structure

Implementation Blueprint

Small Business Playbooks

Consulting Process

Back-Office / Accounting Department Playbook

Back-office / accounting department playbook

Department profile

Role definition

Standard operating procedures

Input sources

Outbound interfaces

Escalation rules

JSON message flow (simplified)

Audit trail

Staged evolution

Cross-references

​Back-office / accounting department playbook

​Department profile

​Role definition

​Standard operating procedures

​Input sources

​Outbound interfaces

​Escalation rules

​JSON message flow (simplified)

​Audit trail

​Staged evolution

​Cross-references

Back-office / accounting department playbook

Department profile

Role definition

Standard operating procedures

Input sources

Outbound interfaces

Escalation rules

JSON message flow (simplified)

Audit trail

Staged evolution

Cross-references