Automate Month-End Close & Transaction Categorization with n8n + Claude Step-by-Step Guide

2. System Architecture

Seven components, each replaceable. The orchestration layer is self-hosted n8n so the auditor can inspect every API call that touches financial data. Postgres is the system of record for raw transactions, categorization decisions, the audit log, and approval state — the GL itself stays in QuickBooks or Xero.

The stack

Cost estimate (4,200 transactions/month, 3 entities)

A senior accountant who reclaims 80 hours per month is worth roughly $6k of fully-loaded cost. The pipeline pays for itself inside the first close, and the cumulative ROI is dominated by what the team does with those reclaimed hours — typically FP&A, board reporting, and SOC 2 evidence collection. The same orchestration layer slots into our broader AI automation services.

Three sources feed the pipeline every night: the bank/credit-card feed via Plaid, the unreconciled transaction list from QuickBooks or Xero, and the vendor master plus chart of accounts (read once per day, cached locally). Plaid is the safety net — it catches transactions that hit the bank but never landed in QBO because of a feed glitch, which is the single most common cause of “missing $4,800” mysteries on close day.

Webhook & poll sources

• Plaid Transactions: nightly /transactions/sync per institution. Cursor-based, idempotent.
• QuickBooks Online: daily query of Purchase, JournalEntry, Bill, CreditCardPayment via the v3 API.
• Xero: equivalent through BankTransactions + ManualJournals with If-Modified-Since.
• COA + Vendors: pulled once per day, normalized into a flat lookup table the Claude prompt can reference cheaply.

Normalized transaction schema

All four sources are normalized into one row shape before they hit categorization. The source_hash is the dedupe key — same source + same external_id = same row, regardless of how many times the workflow re-runs.

CREATE TABLE staged_transactions (
  id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_id       text NOT NULL,
  source          text NOT NULL,    -- 'plaid' | 'qbo' | 'xero'
  source_hash     text NOT NULL,    -- sha256(source || external_id)
  external_id     text NOT NULL,
  posted_at       date NOT NULL,
  amount_cents    bigint NOT NULL,
  currency        text NOT NULL,
  raw_description text NOT NULL,
  counterparty    text,
  account_ref     text,             -- bank acct or QBO acct id
  payload         jsonb NOT NULL,
  ingested_at     timestamptz DEFAULT now(),
  UNIQUE (source_hash)
) PARTITION BY RANGE (posted_at);

A traditional rules-based categorizer breaks the moment marketing spins up a new SaaS subscription or HR adds a benefits vendor. Claude reads the transaction plus the chart of accounts, the vendor history, and the prior-month decision for the same counterparty, and returns a structured JSON with confidence and reasoning. High-confidence rows post automatically; low-confidence rows go to the exception queue.

The 4 categorization dimensions

Categorization system prompt

The COA, class list, and capitalization policy are injected into the prompt context every run. Vendor history is supplied as the most recent five categorizations for the same counterparty — this is what gives Claude its memory and what lets the team override past decisions cleanly.

You are a transaction categorizer for a US GAAP SaaS company.

You receive:
- A single bank or ledger transaction
- The full chart of accounts (account number, name, type)
- The class / department list
- The capitalization policy (threshold $2,500, useful life rules)
- The 5 most recent categorizations of the same vendor

Output strict JSON:
{
  "gl_account": "6310",
  "gl_account_name": "Software Subscriptions",
  "class": "Engineering",
  "capex_vs_opex": "opex",
  "accrual_flag": false,
  "confidence": 0.0-1.0,
  "reasoning": "1-2 sentences citing the strongest signals",
  "needs_human_review": true|false
}

Rules:
- If confidence < 0.85, set needs_human_review = true
- If amount > $2,500 AND counterparty looks like equipment/hardware,
  capex_vs_opex = "capex" and needs_human_review = true regardless
- If service period in description spans month-end, accrual_flag = true
- If counterparty doesn't match anything in the vendor master and the
  amount is > $1,000, needs_human_review = true
- NEVER invent a GL account that doesn't exist in the supplied COA

n8n HTTP Request to Claude

{
  "method": "POST",
  "url": "https://api.anthropic.com/v1/messages",
  "headers": {
    "x-api-key": "{{ $credentials.anthropic.apiKey }}",
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
  },
  "body": {
    "model": "claude-sonnet-4-5",
    "max_tokens": 500,
    "system": "{{ $json.categorizerSystemPrompt }}",
    "messages": [
      {
        "role": "user",
        "content": "Transaction:n{{ JSON.stringify($json.txn) }}nnVendor history (last 5):n{{ JSON.stringify($json.vendorHistory) }}nnCOA + classes attached above."
      }
    ]
  }
}

Vendor memory (the cheap-but-critical bit)

Repeat vendors don’t need full Sonnet calls. A small Postgres lookup + Haiku verification handles ~85% of monthly volume at a tenth of the cost.

-- Last 6 months of accepted categorizations per vendor.
-- If 5+ rows agree on the same gl_account, it's a "settled" vendor —
-- route through Haiku for a sanity check, skip the Sonnet call.

WITH stable AS (
  SELECT counterparty,
         gl_account,
         class,
         count(*)                                            AS hits,
         max(approved_at)                                    AS last_seen
  FROM   categorization_decisions
  WHERE  approved_at > now() - interval '6 months'
    AND  reviewer_action IN ('accepted','auto')
  GROUP  BY counterparty, gl_account, class
  HAVING count(*) >= 5
)
SELECT s.*
FROM   stable s
WHERE  s.counterparty = $1
ORDER  BY s.hits DESC, s.last_seen DESC
LIMIT  1;

Reconciliation is mechanical: bank balance from Plaid must equal the GL cash account balance per QBO/Xero, less in-flight items (uncleared checks, deposits in transit). The pipeline computes both sides, surfaces every break with its likely cause, and only escalates the breaks that don’t auto-resolve. Most months, the human only sees breaks worth seeing.

Three-way recon contract

• Bank-side: Plaid balance at month-end close cutoff (T+1, 4am UTC).
• Ledger-side: QBO/Xero cash account balance as of month-end, with all approved transactions posted.
• Subledger-side: uncleared checks + deposits in transit + pending wires from the n8n staging table.

If bank = ledger + subledger, post the close-ready flag for that account and move on. Otherwise, drop into break analysis.

Auto-resolved break patterns

Break SQL

-- For each bank account, compute the three-way and emit any break.

WITH bank AS (
  SELECT entity_id, account_ref, balance_cents
  FROM   plaid_balances
  WHERE  as_of = $1::date
),
ledger AS (
  SELECT entity_id, account_ref, sum(amount_cents) AS balance_cents
  FROM   ledger_transactions
  WHERE  posted_at <= $1::date
    AND  status = 'posted'
  GROUP  BY entity_id, account_ref
),
subledger AS (
  SELECT entity_id, account_ref, sum(amount_cents) AS in_flight_cents
  FROM   staged_transactions
  WHERE  posted_at <= $1::date
    AND  cleared_at IS NULL
  GROUP  BY entity_id, account_ref
)
SELECT b.entity_id,
       b.account_ref,
       b.balance_cents
         - coalesce(l.balance_cents, 0)
         - coalesce(s.in_flight_cents, 0)        AS break_cents
FROM   bank b
LEFT   JOIN ledger    l USING (entity_id, account_ref)
LEFT   JOIN subledger s USING (entity_id, account_ref)
WHERE  abs(
         b.balance_cents
         - coalesce(l.balance_cents, 0)
         - coalesce(s.in_flight_cents, 0)
       ) > 0;

Anomaly detection runs after categorization but before close. Three layers: a deterministic statistical layer (cheap, catches most things), a duplicate-payment hash check, and a Claude pass over the suspect set with full vendor and seasonality context. The goal is not “find every weird transaction” — it’s “produce a small, ranked queue the controller can clear in 30 minutes.”

Statistical layer

• Vendor amount z-score: any transaction more than 3 standard deviations from the trailing 12-month median for that vendor.
• New vendor > threshold: first-time counterparty with amount above $5,000.
• GL spike: account balance up >30% MoM with no expected driver flagged.
• Round-number cluster: 3+ identical round-amount payments same week to same vendor (a classic kiting signal).
• Period cutoff drift: service-period dates straddle the month boundary without an accrual.

Duplicate payment hash

-- Same vendor, same amount, within 7 days = candidate duplicate.
-- Distinguishes legit recurring (rent) by checking established cadence.

SELECT a.id        AS suspect_id,
       b.id        AS twin_id,
       a.counterparty,
       a.amount_cents,
       a.posted_at AS suspect_posted,
       b.posted_at AS twin_posted
FROM   ledger_transactions a
JOIN   ledger_transactions b
  ON   a.counterparty = b.counterparty
 AND   a.amount_cents = b.amount_cents
 AND   a.entity_id    = b.entity_id
 AND   a.id          <> b.id
 AND   abs(a.posted_at - b.posted_at) BETWEEN 1 AND 7
WHERE  a.posted_at BETWEEN $1 AND $2
  AND  NOT EXISTS (
         SELECT 1 FROM vendor_recurring_cadence r
         WHERE  r.counterparty = a.counterparty
           AND  r.expected_freq_days BETWEEN 1 AND 7
       );

Claude triage of the suspect set

The statistical layer typically produces 80–150 candidates per close. Claude reads each one with full vendor context (last 12 months, average cadence, prior anomaly outcomes) and ranks them by audit risk. The top 20 land in the controller’s queue with a one-paragraph summary of what’s unusual. The rest get a “low-risk, monitoring only” tag and roll forward.

Recurring accruals are the lowest-judgment, highest-volume part of close — exactly where Claude earns its monthly cost. The pipeline reads the accrual policy, the prior-month JE register, and the current month’s posted activity, then drafts every JE the controller would have drafted by hand. The controller still has to approve each one; nothing posts to the GL automatically.

JEs the pipeline drafts

• Prepaid amortization: annual SaaS contracts, insurance, audit retainer.
• Accrued expenses: services received but not yet invoiced (legal, contractors, AWS partial-month).
• Deferred revenue release: recognize revenue per ASC 606 schedule, by contract.
• Depreciation: straight-line on the fixed-asset register.
• FX revaluation: month-end translation for foreign-currency cash and AR/AP.
• Bonus accrual: based on quarterly attainment vs target — controller signs off on the rate.

JE draft payload (QuickBooks)

{
  "TxnDate": "2026-04-30",
  "DocNumber": "JE-2026-04-018",
  "PrivateNote": "Drafted by Claude. Source: prepaid policy + Datadog annual.",
  "Line": [
    {
      "Amount": 4166.67,
      "DetailType": "JournalEntryLineDetail",
      "Description": "Datadog Pro annual / monthly amortization",
      "JournalEntryLineDetail": {
        "PostingType": "Debit",
        "AccountRef": { "value": "6310", "name": "Software Subscriptions" },
        "ClassRef":   { "value": "ENG",  "name": "Engineering" }
      }
    },
    {
      "Amount": 4166.67,
      "DetailType": "JournalEntryLineDetail",
      "Description": "Release prepaid Datadog month 1 of 12",
      "JournalEntryLineDetail": {
        "PostingType": "Credit",
        "AccountRef": { "value": "1410", "name": "Prepaid Expenses" }
      }
    }
  ],
  "MetaData": {
    "skru_status":      "draft_pending_approval",
    "skru_model":       "claude-sonnet-4-5",
    "skru_workpaper":   "s3://skru-close/2026-04/wp-018.pdf"
  }
}

The close package is what the controller signs, the audit committee reads, and the SOC 2 auditor inspects 18 months later. Generating it from a deterministic template (instead of a half-formatted Google Doc reassembled each month) means the format is consistent, the workpapers are linked, and the binder hashes verifiably match the GL state at signing time.

Binder structure

1. Cover & sign-off — period, entity, preparer, reviewer, controller, hash of the GL snapshot.
2. Financial statements — P&L, BS, cash flow, with prior-period and budget comparison.
3. Reconciliations — every cash, AR, AP, and payroll account, three-way recon attached.
4. Journal entry register — every JE this period with workpaper link.
5. Anomaly resolutions — what was flagged, who approved, what the resolution was.
6. Variance commentary — Claude-drafted MoM and YoY commentary, controller-edited.
7. Audit log — every API call, model version, prompt hash, and human action timestamp.

Variance commentary prompt

You are drafting variance commentary for the close binder.

Inputs:
- Current month P&L by GL account
- Prior month and prior-year same-month P&L
- Budget for the current month
- Categorization decisions and notable anomalies for the month
- Major contract starts/ends in the period

For each line where MoM or vs-budget variance is > 10% AND
> $5,000 absolute, write 1-2 plain-English sentences explaining
the most likely driver. Cite specific transactions or contracts.
Never speculate beyond the supplied data. If you don't know, say
"driver not identified — controller review required".

Output format: markdown bullet list, grouped by P&L section
(Revenue, COGS, OpEx, Other), one bullet per material line.

PDF render + immutable archive

The binder is rendered with a headless Chromium n8n node from a versioned HTML template. The output PDF is hashed (SHA-256), uploaded to S3 with object lock enabled, and the hash is written to the audit table. Re-generating the binder for the same period produces a different file (different timestamps) but the underlying GL snapshot hash stays identical — that’s the integrity check the auditor cares about.

Once the binder is generated, distribution is mechanical and time-bound. The controller gets a Slack DM with the binder link and the exception queue. The CFO gets an email summary plus the PDF. The audit committee gets a read-only S3 share with versioned access. Every step writes to the audit log with a timestamp.

Approval state machine

A signed binder is hashed once more, archived to S3 with object lock, and the JEs that were in draft_pending_approval are batched into a single posting transaction to QBO/Xero. The pattern keeps the GL clean — nothing posts before sign-off, nothing posts after sign-off without a documented amendment. The same handoff pattern shows up in our work for consulting industry automations where partners need irrevocable sign-off on client deliverables.

Common Failures & Fixes

Three failure modes show up in nearly every accounting deployment. Plan for them on day one — they are cheap to design around and expensive to retrofit.

Failure 1: Over-confident categorization on edge vendors

Symptom: A new SaaS vendor whose name resembles an existing one (e.g. “Notion” vs “Notion AI”) gets auto-categorized at 0.93 confidence and posted under the wrong department.

Fix: Cap auto-post confidence at 0.95 and require two prior agreeing decisions for the exact normalized vendor string before any auto-post. New vendors always need human review on first appearance, regardless of how confident the model sounds.

Failure 2: Plaid feed reconnect erases prior cursor

Symptom: An entity re-authenticates Plaid (rotating MFA), the cursor resets, and the next sync re-ingests three months of transactions as new — Claude re-categorizes everything and the audit trail looks like the team posted the period twice.

Fix: Always dedupe in the staging table on source_hash first. Skip Claude entirely for any transaction whose source_hash already has an approved categorization decision in the last 18 months — short-circuit to the prior decision and log the fact.

Failure 3: JE draft posts before approval (dev-mode oops)

Symptom: A workflow change is deployed without the right environment flag and Claude-drafted JEs post directly to the live QBO instead of staying in draft_pending_approval.

Fix: The QBO/Xero credential used by the pipeline must be a service account whose role explicitly forbids posting JEs without the approved_by field set. Configure permissions at the integration layer, not just in workflow code — code can ship broken; permissions can’t.

Compliance: SOC 2, Audit Trail & Segregation of Duties

An accounting pipeline that writes to the GL or even drafts JEs is in scope for SOC 2 Type 2 from day one if you’re a SaaS vendor, and for the financial statement audit if you’re a portfolio company over the materiality threshold. Treat compliance as a design constraint, not a checklist at the end.

What Claude sees (and doesn’t)

• Sees: transaction descriptions, amounts, vendor names, GL account list, class list, vendor history (last 5 decisions), capitalization policy, ASC 606 schedules.
• Doesn’t see: bank account numbers, payment card data, employee SSNs, customer PII beyond company name, raw bank login credentials, file attachments outside whitelisted PDF/CSV types.

SOC 2 Type 2 controls this satisfies

• CC7.2 / CC8.1 audit trail: every categorization, JE draft, anomaly resolution, and approval recorded with reviewer, timestamp, model version, and prompt hash.
• CC6.1 access controls: service-account-only writes to QBO/Xero, role-based n8n credentials, no shared API keys per human, vault-backed secrets.
• CC8.1 change management: n8n workflows live in git, CI deploys with approval, no point-and-click prod edits, prompt versions tagged.
• A1.2 / PI1.4 data integrity: close-binder hash chain, S3 object lock, partition retention 7 years, immutable workpapers.

Segregation of duties

The pipeline never closes the loop on its own work. The same identity that drafted a JE cannot approve it; the same identity that approved a JE cannot sign the binder. Senior accountant approves categorizations and JE drafts; controller approves anomaly resolutions and the binder; CFO signs. Three identities, three actions — encoded as a hard constraint in the approval state machine, not as a policy you remember to follow.

Measured Results — 6 Closes In

Numbers from a real implementation at a 200-person SaaS finance team (3 entities, 2 currencies, ~4,200 transactions/month) after six full close cycles on the new pipeline. No change in chart of accounts or close calendar — the lift comes entirely from automation depth and exception-based review.

The headline metric inside the controller’s office is the auto-acceptance rate on categorizations: 93% of high-confidence rows posted without edit, with a measured error rate below 0.4% on a sampled audit. That’s the number that lets finance leadership trust the pipeline enough to actually change behavior — and it’s the number the SOC 2 auditor asked for first.

Implementation Timeline & Cost

FAQ