Intercompany reconciliation is one of the most thankless jobs in the finance function. Every month, controllers and their teams chase balances across dozens of legal entities, matching AR against AP, reconciling intercompany revenue against intercompany expense, and hunting down the small timing differences that make consolidated reporting a nightmare. The work is repetitive, detail-heavy, and unforgiving: a single unposted invoice or a mispriced transfer can cascade into elimination errors, audit findings, and late closes. Most teams handle it in spreadsheets stitched together with VLOOKUPs, email threads, and a great deal of patience.
The core friction is not that the reconciliation logic is hard. It is that the same logic has to be applied manually to hundreds or thousands of transaction pairs every single period, across systems that do not talk to each other cleanly. Entity A records an invoice on the 30th; Entity B books it on the 2nd of the following month. A transfer price is set in one currency and settled in another. A chargeback is recorded gross in one ledger and net in another. Each of these is a small, solvable problem, but multiplied across an entire group, they consume days of skilled finance time that should be spent on analysis, not matching.
Claude Code changes the economics of this work. Unlike a chat interface, Claude Code operates directly on your files: it can read exported ledgers, transaction listings, and reconciliation templates, reason across them, and produce structured outputs you can review and act on. You describe the reconciliation rules once, point it at the period’s data, and it does the matching, flags the exceptions, and drafts the commentary. The controller stays in control, but the mechanical grind disappears.
Why a structured prompt matters here
Intercompany reconciliation fails in predictable ways when automated naively: entity name mismatches, currency rounding, cutoff timing, and one-sided entries. A vague prompt produces a vague match. The prompts below are built around an anatomy that forces you to define success criteria, supply reference material, and make Claude Code ask clarifying questions before it touches your data. That last step is what separates a reliable reconciliation workflow from a plausible-looking mess.
First, read these files completely before responding:
[ic_policy.md] — our intercompany accounting policy: matching rules, materiality thresholds, FX treatment, and cutoff conventions
[entity_mapping.md] — the mapping of entity codes to legal names, functional currencies, and system identifiers
[sample_recon_template.md] — the layout and commentary style of our existing monthly reconciliation pack
Here is a reference for what I want to achieve:
[Upload last month’s completed reconciliation pack as markdown]
Here’s what makes this reference work:
Exception commentary is one line per item, states the counterparty, the amount, the root cause, and the owner. Balances are shown net and gross. Timing differences are separated from true breaks. Tone is factual, no hedging, no narrative padding.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A step-by-step reconciliation workflow plus an exception log template, roughly one page each
Recipient’s reaction: The controller should read it and think “I can run this on Monday” — clear ownership, clear sequence, no ambiguity
Does NOT sound like: A generic best-practice article, or a wall of caveats with no operational steps
Success means: My team can execute the workflow end to end without asking me a single clarifying question, and every exception in the log has an owner and a root cause
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.
Notice what the first prompt does not do: it does not ask Claude Code to reconcile anything yet. It asks for a workflow and a template, grounded in your own policy and your own prior output. This is deliberate. The workflow is the asset you reuse every period; the reconciliation itself is just an execution of it. Get the workflow right once, and each subsequent close becomes a data exercise rather than a design exercise.
From workflow to execution
Once the workflow exists, the second prompt turns it loose on the period’s actual data. The key discipline here is scoping: give Claude Code the transaction extract, the entity mapping, and the workflow it just built, and require it to report exceptions rather than silently resolve them. Any tool that “fixes” intercompany differences without telling you is a liability, not an asset. You want a complete, auditable exception list with a proposed treatment for each item, and you want the reasoning visible.
First, read these files completely before responding:
[ic_workflow.md] — the reconciliation workflow and matching rules we agreed on last session
[entity_mapping.md] — entity codes, legal names, functional currencies, system identifiers
[ic_transactions_[period].md] — this period’s intercompany transaction extract, both AR and AP sides
[prior_exception_log.md] — last period’s exception log, for continuity on recurring items
Here is a reference for what I want to achieve:
[Upload last period’s exception log as markdown]
Here’s what makes this reference work:
One row per exception, columns for entity pair, amount, currency, root cause category, proposed treatment, owner, and status. Recurring items are flagged as recurring with a reference to the prior period. Nothing is resolved silently — every difference appears in the log.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A complete exception log in the same column structure, plus a short summary of matched volume versus exception volume
Recipient’s reaction: The controller should be able to approve or reject each proposed treatment in a single review pass, with no rework
Does NOT sound like: A summary that hides small items, or a log that merges distinct root causes into one vague category
Success means: Every unmatched or partially matched pair is accounted for, recurring items are linked to prior periods, and the total of proposed adjustments ties to the difference between consolidated IC receivables and payables
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.
The practical tip that matters most: run the second prompt on a single entity pair first, not the whole group. Validate the matching logic and the exception categories against a pair you already understand well, correct the workflow if needed, then scale to the full population. This costs one extra cycle and saves you from reviewing a thousand-row exception log built on a flawed rule.
What to try next: extend the same anatomy to the elimination journal entries themselves. Once exceptions are logged and approved, a third prompt can draft the elimination entries and the consolidation commentary from the approved log, closing the loop from raw extract to reported numbers. Keep the ask-clarifying-questions rule in every prompt — it is the cheapest control you will ever build into an automated close.
Published on 17 October 2026 on growwithgpt.com