For any finance team running a consolidated close, intercompany eliminations are the bottleneck that never seems to shrink. The process is deceptively simple: match one entity’s receivable against another’s payable, eliminate both, and remove any corresponding revenue and expense. In practice, however, this is a swamp of mismatched timestamps, FX rate disagreements, missing trade references, and the eternal “we posted it on the 2nd, they posted on the 5th” problem. When your entities operate in different ERP systems—or worse, the same ERP with different chart of accounts—the matching rate often falls below 70%. That remaining 30% becomes a manual scavenger hunt through PDF statements, email threads, and spreadsheets that were last touched in 2019.
The pain is not just the hours spent; it is the risk. Every unmatched balance that rolls into the consolidated financials is a potential audit finding, a restatement trigger, or a reason your external auditor extends their fieldwork. Controllers end up making judgment calls on immaterial differences, but those calls accumulate into material misstatements. The traditional fix—hiring more analysts during close week—is expensive and still error-prone. The better fix is to apply AI to the matching logic itself. Large language models can read the unstructured context around each transaction—invoice numbers, purchase order references, shipping notices, even the notes field where a clerk typed “please match to invoice 8823” in free text—and resolve those matches with a confidence score. The AI does not replace your judgment; it replaces the tedious, low-value pattern recognition that consumes your team’s brainpower.
What does this look like in practice? You feed the AI a consolidated trial balance extract and a list of intercompany balances from each entity. The tool then proposes elimination entries, flags matches that require human review, and produces a working paper that documents its reasoning. The output is not a black box; it gives you the evidence trail you need for the audit file. The result is a close that finishes in days, not weeks, and a matching rate that climbs from 70% to 95% or higher. Below are two ready-to-use prompts that you can adapt to your own consolidation tooling—whether you are using Claude, GPT, or a similar LLM interface.
Why the Prompt Structure Matters for Finance Work
Finance professionals are trained to be skeptical. You do not trust a number unless you can trace it back to source documents. The same logic applies to AI prompts. A vague prompt like “help me match intercompany transactions” will produce a vague, often hallucinated, output. The structured prompt template below forces the AI to act like a junior analyst: read the files, identify the matching criteria, ask clarifying questions, and only then produce a plan. This is critical because intercompany matching is not a single rule—it is a set of heuristics that vary by entity, currency, and materiality threshold. By uploading your own reference files (e.g., a sample of last quarter’s successfully matched pairs), you teach the AI your specific definition of a “match.”
The second prompt in this post goes a step further: it asks the AI to generate the actual elimination journal entries, complete with FX revaluation and a breakdown of permanent vs. temporary differences. This is where the real time savings happen. Instead of manually rekeying entries from a matching spreadsheet into your consolidation system, you get a draft that your team can review and post. The prompt includes explicit instructions to flag anything ambiguous, so you are not blindly trusting the output. Let’s get into the prompts themselves.
First, read these files completely before responding:
[IC_balances_Q2.xlsx] — Contains all intercompany receivable and payable balances by entity, currency, and period, with columns for entity code, counterparty, amount, currency, and posting date.
[IC_transactions_detail.csv] — Line-item detail for every intercompany transaction, including invoice number, PO reference, description field, and original entry date.
[prior_matches_sample.xlsx] — A sample of 200 pairs that were successfully matched and eliminated in the last quarter, including the reasoning notes added by our senior analyst.
Here is a reference for what I want to achieve:
The file [prior_matches_sample.xlsx] shows the exact format and logic our team used to approve matches. Each row includes a match confidence score (High/Medium/Low), a short justification text, and the netting rule applied (gross vs. net).
Here’s what makes this reference work:
– Matches are considered valid only if the currency matches exactly OR the FX difference is within 0.5% and clearly documented.
– The description field often contains the counterparty’s invoice number in free text (e.g., “ref: INV-2231”), which should be extracted and used as a primary key.
– Balances are netted only when both entities agree on the amount to the nearest currency unit; otherwise, the difference is flagged as a “pending dispute.”
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A structured table with columns [Match ID, Entity A, Entity B, Amount A, Amount B, FX Difference, Confidence Score, Proposed Action (Eliminate/Review/Dispute), Justification Text] — maximum 200 rows.
Recipient’s reaction: They should be able to post the “Eliminate” rows directly without further research, and they should see a clear list of only 10-15 “Review” items that require their judgment.
Does NOT sound like: A generic list of “possible matches” without evidence. No vague phrases like “likely related” or “appears to correspond.” Every row must cite the specific invoice number, PO reference, or description field that drove the match.
Success means: The output reduces the manual review population from 300 unmatched items to fewer than 50, and every proposed elimination entry can be traced back to a source transaction in the CSV.
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.
That first prompt is your discovery tool. It forces the AI to read your actual data and your historical matching logic before it proposes anything. The clarifying questions it asks will often reveal gaps in your own data—for example, you might realize that one entity never includes the PO reference in their posting description, which is why their matches always fail. The key is to run this prompt on a small sample (e.g., just one entity pair) before scaling to the full consolidation. This lets you validate the AI’s matching logic against your own manual results without risking a garbage-in, garbage-out disaster across all entities.
Once the AI has proven it can match accurately, the second prompt below shifts from matching to elimination entry generation. This is where you turn the matched pairs into actual journal entries that your consolidation system can import. The prompt explicitly asks for the AI to handle FX revaluation, which is often the most error-prone manual step. It also asks for a clear distinction between permanent differences (e.g., a true mismatch that needs a write-off) and temporary differences (e.g., timing lags that will reverse next month). This distinction is what your auditors will look for, so having the AI articulate it upfront saves you a week of back-and-forth.
First, read these files completely before responding:
[matched_pairs_output.xlsx] — The output from the previous matching step, containing Match ID, Entity A, Entity B, Amounts, FX Difference, Confidence Score, and Proposed Action.
[consolidation_chart_of_accounts.csv] — Our group-level chart of accounts, including account codes for intercompany payables, receivables, revenue, and expense, plus the FX revaluation account code.
[FX_rates_monthly.xlsx] — Month-end FX rates by currency pair, used for revaluing any balances posted in a non-functional currency.
Here is a reference for what I want to achieve:
A sample journal entry template from last quarter’s close is included as [JE_template.xlsx]. It shows the standard debit/credit structure, the use of a single “Intercompany Elimination” account for netting, and the separate line for FX revaluation gains/losses.
Here’s what makes this reference work:
– Each elimination entry uses the group-level account codes, not the local entity codes.
– FX revaluation is calculated at the month-end rate, and the difference is booked to account 9800 (FX Revaluation) with a clear narration referencing the original transaction date.
– Permanent differences (e.g., a disputed charge that will not reverse) are booked to a separate “Sundry Loss” account with full documentation.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A complete set of journal entries in a table format with columns [Entry ID, Date, Entity A Code, Entity B Code, Account Code, Debit Amount, Credit Amount, Narration]. Maximum 250 rows.
Recipient’s reaction: The controller should be able to review the entries in under 30 minutes and post them without needing to look up a single account code or FX rate.
Does NOT sound like: A summary of “what needs to be done.” This must be an actual journal entry file, ready for import. No placeholders like “insert amount here.” Every line must have a real number.
Success means: The entries balance to zero for each entity pair, the FX revaluation lines match the month-end rates exactly, and the total eliminated amount ties to the original intercompany balances report.
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.
When you run the second prompt, expect the AI to ask about your posting date conventions and whether you net by entity pair or by currency. Answer those questions clearly, and then let it generate the entries. One practical tip: do not run this on the full dataset on your first attempt. Instead, take a subset of one entity pair with about 50 matched transactions. Review the generated entries against your own manual calculation for that same pair. If the AI’s entries match your manual work to the penny, then scale up. If there is a discrepancy, it is almost always in the FX revaluation logic—so check that the AI is using the same rate source and rounding rules as your team.
What should you try next? After you have automated matching and elimination entries, the next frontier is automating the intercompany reconciliation statement that goes to your audit committee. You can use the same prompt structure to ask the AI to draft a narrative explanation of the top 10 unmatched items, including the root cause (e.g., “Entity A posted in EUR, Entity B posted in USD, FX rate used differed by 0.2%”). That narrative is often the most time-consuming part of the close, and it is exactly the kind of structured writing that LLMs excel at. Start with these two prompts, refine them on your own data, and you will reclaim days from your close cycle.
Published on 6 August 2026 on growwithgpt.com