Intercompany reconciliation is one of the most persistent bottlenecks in the month-end close. Every legal entity in a group must agree with every counterparty on balances, transactions, and transfer pricing entries — and in most organizations, that agreement is reached through a patchwork of spreadsheets, email chains, and late-night calls between controllers in different time zones. The numbers rarely match on the first pass. Differences sit in transit, in foreign exchange translation, in misposted journal entries, or in timing gaps that no one documented. The result is a close that drags, audit risk that compounds, and a finance team that spends its most expensive hours on mechanical matching instead of analysis.
The core friction is structural. Intercompany data lives in multiple ERPs, each with its own chart of accounts, its own currency conventions, and its own cut-off discipline. Matching rules change as the group acquires entities or restructures. Tick-and-tie work that should take minutes takes days because someone has to manually pull counterparty balances, normalize the formats, and chase down the exceptions one by one. And because the logic lives in individual spreadsheets rather than in a governed, repeatable process, every close reintroduces the same errors.
Claude Code changes the economics of this work. As an agentic tool that reads files, writes scripts, and executes multi-step analysis in your working directory, it can ingest exported trial balances and intercompany ledgers, normalize them against a defined mapping, run the matching logic, classify exceptions by root cause, and produce a reconciliation workpaper with a clear audit trail. You define the rules and the standards; Claude Code does the mechanical matching and documents its reasoning. The controller reviews exceptions instead of building the reconciliation from scratch.
What to prepare before you prompt
The quality of the output depends almost entirely on the quality of the inputs. Before you start, export the intercompany balances for both sides of each reconciliation — typically a group intercompany matrix from consolidation and a counterparty ledger from each entity’s ERP. Export them as CSV or markdown. Write down your matching rules: which fields must agree, what tolerance is acceptable, how FX differences should be treated, and which entity pairs are in scope. If you have a prior-month reconciliation workpaper that your auditors accepted, keep it as a reference — it encodes the format and level of documentation your team already trusts.
Claude Code works best when it is asked to plan before it executes. The prompt below forces that discipline: it requires a full read of your context files, a restatement of the reference patterns, and an execution plan before any matching begins. That structure is what keeps the output reviewable.
First, read these files completely before responding:
[ic_matrix_export.csv] — group intercompany balances by entity pair, in group currency, as exported from the consolidation system
[counterparty_ledgers.csv] — entity-level intercompany ledger balances by counterparty, in local currency
[fx_rates.md] — closing and average rates by currency pair for the period
[recon_rules.md] — my matching rules: fields that must agree, materiality tolerance, FX treatment, in-scope entity pairs
[prior_month_workpaper.md] — last month’s accepted reconciliation workpaper
Here is a reference for what I want to achieve:
[Attach prior_month_workpaper.md as the reference]
Here’s what makes this reference work:
– Every entity pair has a single summary line showing both sides, the difference, and a status
– Exceptions are grouped by root cause (timing, FX, misposting, missing entry) rather than listed flat
– Each exception carries a one-line explanation and a proposed correcting action
– The workpaper opens with a scope statement and closes with a sign-off block
– Tone is factual and audit-ready; no narrative padding
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: markdown reconciliation workpaper, approximately [N] entity pairs, one summary table plus an exception register
Recipient’s reaction: the controller should be able to review exceptions in under [X] minutes and forward the workpaper to audit without edits
Does NOT sound like: a raw data dump, a list of unmatched rows with no explanation, or a narrative memo
Success means: [PERCENTAGE] of entity pairs matched within tolerance automatically, and every remaining exception assigned a root cause and owner
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
Once the first pass is complete, the second prompt handles the part that consumes the most controller time: the exception register. Matching is mechanical; resolving differences requires judgment about root cause, materiality, and the correct correcting entry. Claude Code can draft that judgment systematically if you give it the right constraints — materiality thresholds, the group’s account mapping, and a clear statement of what a reviewer needs to see before approving a proposed adjustment.
Turning exceptions into a review-ready register
Run this prompt after the first reconciliation pass, pointing Claude Code at the workpaper it produced. The goal is not to eliminate exceptions but to make each one decidable: what happened, how much it matters, who owns the fix, and what entry resolves it. That is the difference between a reconciliation that gets signed off and one that bounces back with questions.
First, read these files completely before responding:
[recon_workpaper.md] — the reconciliation workpaper produced in the previous step, including all unmatched items
[account_mapping.md] — group chart of accounts and the intercompany account pairs used for correcting entries
[materiality_policy.md] — group materiality thresholds by entity and by account type
[resolution_log.md] — prior-period exceptions and how they were resolved, for pattern reference
Here is a reference for what I want to achieve:
[Attach a prior exception register or describe the format your audit team expects]
Here’s what makes this reference work:
– One row per exception with entity pair, accounts, amounts on both sides, and the difference
– Root cause assigned from a fixed taxonomy: timing, FX translation, misposting, missing entry, mapping error
– Materiality flag computed against the policy thresholds, not estimated
– Proposed correcting entry stated as debit and credit with account codes
– Owner and target resolution date on every row
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: markdown exception register, one table, plus a short summary of exceptions by root cause and by materiality
Recipient’s reaction: the controller should be able to approve, reject, or reassign each exception in a single review pass
Does NOT sound like: a vague list of differences, or proposed entries without account codes and amounts
Success means: every exception has a root cause, a materiality flag, and a proposed entry, with zero rows left unclassified
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
A practical tip: keep your reconciliation rules and account mapping in version-controlled markdown files rather than inside the prompt. When the group restructures or a new entity is onboarded, you update one file and every subsequent run inherits the change. That is what turns this from a one-off exercise into a governed process your auditors can trace.
Start with a single entity pair and a single close period. Validate the workpaper against your prior month’s accepted version, then expand the scope entity by entity. The first run will surface gaps in your rules file — that is expected. Each gap you close makes the next close faster, and by the third period the reconciliation becomes a review task rather than a build task.
Published on 30 October 2026 on growwithgpt.com