A copy-paste reconciliation prompt pack (the directions AI actually needs)

The most useful thing anyone says about AI in finance is also the most deflating: it only helps if you tell it exactly what to do. The top-voted reply in an r/FPandA thread on whether agentic AI actually makes finance teams more effective put it plainly — "the AI solutions require very clear directions. There is a lot of learning/teaching to be done for the system to answer your questions properly." Right. And almost nobody hands over the directions. So here they are: a copy-paste pack that walks any capable assistant through reconciling two files, in order, with one rule that keeps every number yours to check — the model may parse, propose, and explain, but it never decides whether two numbers are equal. Code does that.

There is no shortage of "use AI to reconcile" advice. What is missing is the actual prompts — the literal text that turns a chatty assistant into a careful one. The other pieces here cover the why and the patterns; this is the grab-and-go version. Copy the prompts below in order, swap in your filenames and key, and you have the "very clear directions" that thread was asking for. Then keep them — the same pack works next month.

The one rule the whole pack is built on

Every prompt here enforces a single division of labor: the model handles language and judgment, code handles matching and math. The reason is not snobbery about AI — it is that a language model asked to total ten thousand rows will hand you a confident number in the same fluent tone whether it is right or invented. That failure has a name, hallucination, and you cannot catch it by reading the answer. So the matching and the arithmetic live in code the assistant writes and runs in front of you, and the model is left doing the parts it is genuinely good at: proposing a field map, guessing a key, sorting a difference list, explaining a row. For the long version of this line, see can an AI agent reconcile your data and the end-to-end walkthrough.

How to use the pack

1. Paste Prompt 0 once at the top of the chat. It sets the standing rules for the whole session so you are not re-typing them.
2. Then paste Prompts 1 through 7 in order, one at a time. Read the output of each before pasting the next — the point is to catch a wrong key or a misread column early, not at the end.
3. Swap the placeholders for your specifics: your two filenames, the join key, and the amount column you are comparing.
4. Use any assistant that can actually run code in a sandbox. The pack is tool-agnostic; the safety comes from what you ask for, not the brand.

Here is what each prompt produces and the specific trap it heads off — skim it once so the order makes sense.

The prompts

These are written to be pasted as-is. The placeholders in angle brackets — <KEY>, <AMOUNT> — are the only things you change. The full set is also a single download if you would rather keep it in a file.

Prompt 0 — standing instructions (paste once)

You are helping me reconcile two data files. Follow these rules for the
whole session:
- Never state a total, count, or difference unless it was printed by code
  you just ran. If you didn't run code for a number, don't give the number.
- Read all ID/key columns as text. Never let an ID become a float.
- Do the matching and arithmetic in code (Python/pandas). Use prose only to
  explain what the code printed.
- When unsure, stop and ask. Do not guess a key, a mapping, or a number.

Prompt 1 — census the files before matching

You are checking the assistant read the files the way you expect. No matching yet. (If it cannot even read them cleanly, that is a CSV gotcha to fix before anything else.)

Here are two files: system_a.csv and system_b.csv.
Do NOT reconcile them yet. First, for each file, run code that prints:
- the column names
- the row count
- 3 sample rows
Then list, side by side, which column in A maps to which column in B. Flag
any format differences (currency units, date formats, casing). No diffs yet.

Prompt 2 — propose the join key (and justify it)

This is the one decision that quietly sinks most reconciliations, so make the model justify it and prove it. It is also where a composite key gets caught — when no single column is unique on its own.

Propose the minimal set of columns that uniquely identifies a row in each
file. Explain why a single column is or isn't enough. If no single column
is unique, propose a composite key. Then run code that counts distinct keys
vs. total rows and prints whether the proposed key is actually unique.
Reason from the column meanings; do not assume.

Prompt 3 — write the merge as readable code

Two arguments do the trust work: indicator=True tags each row left_only / right_only / both, and validate="one_to_one" makes the pandas merge error out loudly if the key is not unique instead of quietly doubling rows.

Write Python (pandas) that:
- reads both files with every ID column as text (dtype=str)
- does an OUTER merge on <KEY>, with indicator=True and validate="one_to_one"
- prints the count of left_only, right_only, and both
Show me the code first. Don't run it until I say go.

Prompt 4 — show only the real differences

The left_only and right_only buckets are the answer, not leftovers — those are the rows in one file and missing from the other, which is usually the whole reason you reconciled.

Go. After the merge, for rows present in BOTH files, compute the difference
in the <AMOUNT> column in code. Print ONLY the rows where the difference is
nonzero, sorted largest-first. Do not summarize the numbers in prose. Also
print the full left_only and right_only rows — those are the missing
records, not noise.

Prompt 5 — classify the differences

Now the model does what it is actually good at: sorting an already-computed list into categories. Note it is told not to touch the numbers — same constraint as the standalone classify pattern.

Here is the list of nonzero differences you just printed. Do NOT change any
numbers. For each row, classify the likely cause as one of: timing,
fee/adjustment, value error, or missing record. Give a one-line reason per
row. Flag any you can't classify with confidence.

Prompt 6 — explain one exception to a human

The model at its best: turning a flagged row into a sentence a reviewer can act on, while being told to flag when the story does not fit the figures.

Take row <KEY=...>. Context: <e.g. order placed May 2, refund issued May 9,
processor fee 2.9% + 0.30>. In two sentences, explain the most likely cause
of the difference for a finance reviewer. If the numbers don't support your
explanation, say so instead of forcing one.

Prompt 7 — verify it did not drop rows

This is the step that separates a number you can defend from a confident guess, and it is the same thing an auditor looks for: completeness, a unique key, totals that tie, and a trail you can follow. Reading IDs as text throughout matters here — a long order number rounded into scientific notation on export is the single most common way a join silently fails.

Print three things so I can check your work:
- the row census again (left_only + right_only + both = total)
- the sum of <AMOUNT> in each original file, before the merge
- 3 specific rows traced end to end, including one that should NOT match
Then I will compare the file totals to a number I already trust.

Why "save the directions" matters more than any single prompt

The reason to keep this pack as a file instead of re-improvising each month is not tidiness. It is that vague, one-off directions are exactly where AI accuracy decays. An r/BusinessIntelligence thread summarizing an AI vendor's internal write-up reported the shape of the problem — "Without skill files, their internal accuracy sits at 21%. With skill files, 95%. Without active maintenance, it drifts back to 65% in a single month." Those are a vendor's own numbers, not an independent benchmark, so hold them loosely. But the direction is the part the practitioners in that thread agreed on, and one commenter named the cause bluntly: "Drift is caused by poor design and lack of reinforcement of system prompts." A saved, reused prompt pack is that reinforcement. You write the directions once, vet them once, and stop re-teaching the model from scratch every close. (For the underlying technique, prompt engineering is just the formal name for "write down the directions and keep refining them.")

When the pack is the wrong tool

Honest limits. This pack shines on the awkward one-off — an odd export, a key you have to reconstruct, a file too messy to wrangle by hand but not worth building a pipeline for. It is not the only answer, and not always the right one.

The purpose-built parsers are genuinely good at what they cover; they are also retrospective money-to-ledger tools locked to specific platforms, which is a different job than matching two arbitrary exports. Use whichever fits the file in front of you — the pack is for when nothing off-the-shelf does.

The whole pack is one idea wearing seven prompts: make the assistant show its work in code, and keep yourself as the person who reads it. Do that and you get the speed the demos promise without trusting a number you cannot defend. If the assistant is ever unavailable, the same logic runs as a by-hand method you control end to end — and either way, a reconciliation you can stand behind is one where you can point at exactly how every number was reached.

← All writing