For finance teams at multinational corporations, intercompany reconciliation is a persistent source of friction. The process typically involves extracting trial balances from multiple ERP systems, mapping inconsistent account codes, matching thousands of transactions across entities, investigating discrepancies that never seem to resolve, and then producing consolidated reports under tight month-end deadlines. A single mismatch between a US entity and its German subsidiary can delay close by days. Controllers spend 40 to 60 percent of their close cycle on intercompany eliminations, and the manual effort introduces human error that compounds over time.
The core pain is structural. Different subsidiaries use different chart of accounts, different currencies, different fiscal periods, and different levels of granularity. A transaction recorded as “IC Revenue” in one system might appear as “Intercompany Sales – Affiliates” in another. Currency conversion rates vary by date and by system. Timing differences from goods-in-transit or service accruals create phantom mismatches that require manual investigation. The result is a cycle of spreadsheets, email chains, and late-night reconciliations that erodes team morale and increases audit risk.
Claude Code changes this equation entirely. By treating reconciliation as a structured data transformation and matching problem, Claude can ingest raw trial balance exports from multiple entities, normalize them against a master chart of accounts, apply currency conversion rules, match transactions using fuzzy logic on multiple fields, flag true exceptions versus timing differences, and produce a reconciliation output with clear action items. The AI does not replace judgment—it replaces the grinding manual work that prevents finance professionals from applying judgment where it matters.
How Claude Code Handles the Heavy Lifting
The key insight is that intercompany reconciliation follows predictable patterns. Debits in one entity should match credits in another. Transaction references, invoice numbers, and counterparty codes provide matching keys. Currency differences follow known rate tables. Timing differences have identifiable characteristics. Claude can be instructed to follow these patterns systematically, across thousands of rows, in minutes rather than days. The prompts below show how to structure Claude’s work for two critical phases of the reconciliation process: initial data ingestion and normalization, and then the matching and exception analysis phase.
First, read these files completely before responding:
[entity_A_trial_balance.csv] — Raw trial balance export for Entity A with columns: Account Code, Account Name, Debit Amount, Credit Amount, Currency, Transaction Date, Reference Number, Counterparty Code
[entity_B_trial_balance.csv] — Raw trial balance export for Entity B with columns: GL Account, Description, Debit, Credit, Currency Code, Posting Date, Document ID, Partner Code
[master_chart_of_accounts.csv] — The standardized chart of accounts mapping all entity-specific account codes to a unified classification
Here is a reference for what I want to achieve:
A month-end intercompany normalization script that reads raw exports, maps account codes using the master chart, converts all amounts to USD using a provided exchange rate table, flags any unmapped accounts, and outputs a clean, standardized dataset ready for matching.
Here’s what makes this reference work:
The script handles multiple input formats gracefully by detecting column headers rather than assuming fixed positions. It logs every unmapped account code for manual review rather than failing silently. Currency conversion uses a date-effective rate table so that transactions on different dates use the correct rate. The output includes a status column indicating whether each row was successfully normalized or requires attention.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A Python script that accepts file paths as arguments, processes Entity A and Entity B files, and writes a single normalized CSV. Approximately 150 to 200 lines.
Recipient’s reaction: The controller should be able to run this script and immediately see a clean file with no errors. They should trust that unmapped accounts are flagged, not silently dropped.
Does NOT sound like: Overly complex with unnecessary object-oriented patterns. No dependencies beyond pandas and standard library.
Success means: The script runs end-to-end on sample data, correctly maps 100 percent of accounts that exist in the master chart, flags any accounts not in the master chart, and converts all amounts to USD at the correct date-specific rate.
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.
Moving from Normalization to Intelligent Matching
Once the data is normalized, the real challenge begins: matching intercompany transactions across entities. This is where Claude’s ability to apply multiple matching strategies simultaneously becomes invaluable. A single transaction might match on reference number, on invoice number plus amount, on counterparty code plus approximate date, or on a combination of fields that would require complex nested formulas in a spreadsheet. Claude can evaluate all these strategies, apply confidence scoring, and separate confirmed matches from candidates requiring human review.
The matching phase also benefits from Claude’s ability to understand context. A timing difference of three days on a goods-in-transit transaction is expected and should be flagged as a timing difference, not an exception. A currency difference that exactly equals the spread between two known rates on a specific date is likely a rate application error, not an actual mismatch. By encoding these business rules into the matching logic, Claude reduces false positives dramatically. The prompt below structures this phase with the same rigor as the normalization phase.
First, read these files completely before responding:
[entity_A_normalized.csv] — Normalized Entity A transactions with columns: Transaction ID, Account Code, Amount USD, Currency, Posting Date, Reference Number, Counterparty Code, Invoice Number, Description
[entity_B_normalized.csv] — Normalized Entity B transactions with identical schema
[exchange_rate_table.csv] — Daily USD exchange rates for all relevant currencies during the reconciliation period
[timing_difference_rules.md] — Business rules defining acceptable timing differences (e.g., 3 days for goods, 5 days for services)
Here is a reference for what I want to achieve:
A matching engine that applies three matching strategies in order of priority: exact reference number match, invoice number plus amount match within 0.5 percent tolerance, and counterparty code plus amount plus date within 3 days. Each match is assigned a confidence score. Unmatched transactions are categorized as true exceptions, timing differences, or currency-only differences.
Here’s what makes this reference work:
The engine processes matches in priority order and does not double-count transactions. It outputs a clear status column: Matched, Timing Difference, Currency Difference, Unmatched. It produces a summary showing match rate, total dollar value matched, and number of exceptions requiring manual review. It handles partial matches where one entity has multiple transactions that sum to a single transaction in the other entity.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A Python script that reads two normalized CSV files and the exchange rate table, performs matching, and writes two output files: a detailed match report CSV and a summary report CSV. Approximately 200 to 250 lines.
Recipient’s reaction: The controller should see a clear, auditable trail of every match decision. They should be able to open the summary report and immediately know the match rate, the dollar value of exceptions, and which transactions need their attention.
Does NOT sound like: A black box that just says “matched” or “unmatched” without explanation. No machine learning jargon or probabilistic models.
Success means: The script correctly matches at least 90 percent of transactions that should match based on the three strategies, correctly identifies timing differences per the business rules, and flags all remaining transactions with a specific reason code.
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.
Practical Implementation Tips for Finance Teams
To get the most out of Claude Code for intercompany reconciliation, start with a single pair of entities rather than attempting the full consolidation at once. Choose two entities with clean, well-structured data and a manageable transaction volume. Run the normalization script first, review the flagged unmapped accounts, and update your master chart of accounts before moving to matching. This iterative approach builds confidence in the process and allows you to refine the business rules in the matching prompt as you see real results.
One common pitfall is expecting perfection on the first run. Intercompany data is messy by nature. You will encounter transactions that do not fit your matching strategies, counterparty codes that are inconsistent, and timing differences that exceed your rules. Treat these as opportunities to refine your prompts and your business rules. Each exception you resolve by updating a rule or adding a mapping makes the next reconciliation faster. Over three to four month-end cycles, you can reduce the manual reconciliation effort by 70 to 80 percent, freeing your team to focus on analysis and strategic decisions rather than spreadsheet drudgery.
Published on 11 July 2026 on growwithgpt.com