Reconcile Two Spreadsheets Without Trusting the Answer

A reconciliation that balances can still be wrong. Two offsetting errors produce a clean total, and one computation cannot detect its own mistake. That is why a two source tie out, run with an assistant, is worth doing in a fixed order rather than in one confident prompt.

The order is the control: reduce and de-identify both extracts, ground the model in them, demand the table and the code together, then recompute the control figures from the raw files before accepting a single line.

The practitioner consequence is an artefact rather than a habit. What survives a review is a working paper carrying every control figure computed twice, with the code file beside it, not a chat window that can be reopened and re-answered differently. Australian record keeping law asks for the method, not just the number.

Why is a tie out the safest first assisted task?

Because the answer is checkable without trusting the model. Two extracts either reconcile or they do not, and the assistants whose own pages describe this work compute the result in code that a person can read.

The vendors say so themselves, in weaker words. OpenAI's help centre page on data analysis with ChatGPT states, as at 25 September 2026, "When ChatGPT uses Python for analysis, review the generated code, outputs, and assumptions before relying on the result." The same page describes an environment in which, for some data analysis tasks, ChatGPT writes and runs Python in a stateful Jupyter notebook, and states that it cannot make external web requests or API calls. It can still write a number into the code from its own training rather than from the file, which is what the grounding sentence in move two exists to stop.

Microsoft's support page for Excel for Microsoft 365, "Get direct answers to your data analysis questions", states "You can expand the code to see how the answer was generated." It also states, as at 25 September 2026, that Copilot "works with single tables or table-like ranges, or multiple such ranges across your workbook" and that "Unstructured data is not supported".

The four moves, in order

TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened.

Applied to this task, that method has four moves, and the order is not decorative.

1. Reduce both files to a de-identified key column, a value column and a date.
2. Upload both and state the grounding, so the model works from the attached files rather than from a general sense of how ledgers behave.
3. Demand two outputs together, the reconciliation table and the code that produced it.
4. Recompute the control figures from the raw files in a fresh conversation, then compare.

The human decision point is moves three and four together. Neither half works alone: code behind one unverified number shows only that the method was reasonable, and two numbers without the code show nothing about what was matched.

Move one: what has to come out of the file first?

Every direct identifier, and then a second look at what is left.

The Office of the Australian Information Commissioner (OAIC) publishes guidance on privacy and the use of commercially available AI products, published 21 October 2024 and updated 17 January 2025, which recommends as a matter of best practice that "organisations do not enter personal information, and particularly sensitive information, into publicly available AI chatbots and other publicly available generative AI tools". It treats that input as a use or disclosure to be justified under Australian Privacy Principle 6, and sets an Australian Privacy Principle 10 accuracy expectation commensurate with the likely increased level of risk in an AI context.

That is why the reduction happens before the upload. Once a file has been sent, the question of whether it should have been is closed.

Stripping a name column is a first step, not a finished answer. The OAIC's guidance on de-identification and the Privacy Act, published 21 March 2018, states "the removal of name, address or other direct identifiers alone may not result in de-identification for the purposes of the Privacy Act", and that "De-identification is a risk management exercise, not an exact science." It sets out two steps: remove the direct identifiers, then remove or alter other information that could still re-identify a person, taking account of the environment the data sits in. The test those steps aim at sits in the Privacy Act 1988, Compilation No. 104, compilation date 4 June 2026: information is de-identified if it is no longer about an identifiable individual or an individual who is reasonably identifiable.

The reduction is easy, because the match does not need the identity. It does need one identifier that already exists on both sides, usually an invoice number, a payment reference or an employee number. Build one mapping table of [ROW_KEY] against that shared identifier and apply it to both extracts, so one record carries one key in File A and in File B. Keep [VALUE_COLUMN] and the transaction date, delete the rest, and hold the mapping inside [ORGANISATION]. Where no identifier is common to the two systems, the match has to be built in the source environment first, because a de-identified tie out has nothing to join on.

Shape matters too. The OpenAI page sets out the file preparation rules that make a spreadsheet readable: descriptive headers in the first row, one row per record, no empty rows or columns splitting the data, and no multiple unrelated tables in one sheet. A header row below the first, or a second table in the same sheet, is enough for a tie out to answer confidently about the wrong columns.

What will each assistant actually accept?

Different numbers, all of them moveable, none of them fixed by law.

OpenAI's file uploads FAQ states, as at 25 September 2026, "For CSV files or spreadsheets, the file size cannot exceed approximately 50MB, depending on the size of each row". Anthropic's page "Upload files to Claude", dated 23 July 2026, states "You must enable code execution and file creation in your account to upload XLSX files", and its companion page "Create and edit files with Claude", dated 6 August 2026, sets the 30MB ceiling. Google's Gemini Apps help page, "Upload & analyze files in Gemini Apps", carries the Gemini figures, as at 25 September 2026.

Two of those numbers sit on different Anthropic pages and neither page reconciles them. Test with the actual file, at the actual size, rather than assuming which one governs.

The practical instruction is smaller than the table. Export both sides as CSV, which avoids the workbook precondition, keeps the file small, and forces the shape rules before the upload. Turn code execution on whatever the file type: a CSV removes the precondition without making the assistant run anything, and code that did not run is not a record of a calculation. On Copilot in Excel the page describes no upload path, so put both extracts in the open workbook as two named tables and replace every mention of the attached files below with [TABLE_A] and [TABLE_B]. Two further steps change: the recomputation runs in a fresh Copilot chat over the same two tables, and the code is expanded in the answer and saved rather than asked for. Check what tier the account is on, a question covered in a piece on account types.

Move two: ground the model in the two files

Grounding is a sentence, not a setting. The prompt has to say the attached files are the only source, and what to do when they do not answer the question.

You are reconciling two de-identified extracts that are attached. Use only the attached files. Do not use any outside knowledge and do not infer values that are not in the files.

File A is [SYSTEM_A_EXTRACT], a ledger extract for [PERIOD]. File B is [SYSTEM_B_EXTRACT], a supplier or payroll listing for the same period. Both files hold three columns only: [ROW_KEY], [VALUE_COLUMN] and a transaction date. [ROW_KEY] is a de-identified key applied to both files from the same mapping. There are no names in either file.

State at the top of your answer whether the figures below were produced by executing code or read from the files directly.

Produce three blocks, in this order.

1. Eight control figures, each on its own labelled line: the row count of each file as read; the total of [VALUE_COLUMN] in each file as read; the total absolute difference in [VALUE_COLUMN] across keys present in both files; the count of keys present in both files; the count present in File A only; and the count present in File B only.

2. One reconciliation table with four buckets: matched and equal; matched with a value variance; present in File A only; present in File B only. For each bucket give the row count and the total of [VALUE_COLUMN]. For the matched with a value variance bucket give three totals, the File A total, the File B total and the total difference. For the last three buckets list every row with its [ROW_KEY], the File A value, the File B value and the difference. Flag any matched row where the two transaction dates differ by more than [TOLERANCE] days.

3. The complete Python that produced the control figures and that table, including how you read each file, how you joined them, how you normalised [ROW_KEY], naming any change of case, stripped whitespace or type coercion, and how you handled duplicate keys, blank values and rounding.

Where anything cannot be determined from the attached files, write "not determinable from the attached files" rather than an estimate. Do not state a cause for any variance.

What to check: that the totals in the prose match the table and the totals the code printed, because these three can disagree. Then that the answer states the code was executed, that the row counts read match the counts exported, that duplicate keys were handled rather than dropped, and that the four buckets add back to both file totals.

Move three: read the code, not the summary

With placeholder keys and round values, the buckets come back in this shape.

Open the code before reading a word of the commentary. Four things in it decide whether that table means anything.

• The join. An inner join discards every unmatched row, the population the reconciliation exists to find: how="inner" returns the matched rows alone, and how="outer" is what puts the last two buckets in front of a reader.
• The key handling. Stripped whitespace, changed case and coerced types are reasonable choices, and each changes which rows match.
• The duplicates. If either file has two rows on one [ROW_KEY], a naive join multiplies them and the value totals inflate with no error shown.
• The rounding. A tie out at two decimal places and one at full precision give different exception lists.

A person writing the same code would note each one in a working paper, and the assistant makes them silently unless asked.

Copilot in Excel needs a further caution. The Microsoft page states, as at 25 September 2026, that Copilot does not modify the workbook, and that inserted tables or images are static and not refreshable. A pasted result that looks live is not, and carries no evidence of what produced it unless the code is kept separately.

Move four: why recompute a total that already balances?

Because one computation cannot check itself, and agreement is the only evidence available without rebuilding the reconciliation by hand.

Australian Privacy Principle 10.2 in the Privacy Act, Compilation No. 104, compilation date 4 June 2026, requires an APP entity to take such steps, if any, as are reasonable in the circumstances to ensure that personal information it uses or discloses is, having regard to the purpose of the use or disclosure, accurate, up-to-date, complete and relevant. Where the reduction has not taken the extract outside personal information, that obligation is live, and a second independent computation is a cheap, evidenced step towards discharging it.

The recomputation has to be genuinely fresh. A prompt that says "check your answer" invites the model to re-read its own working and agree with itself. Open a new conversation and upload the two extracts again, because the analysis environment OpenAI describes is stateful, so a second pass in the same chat can still be reading what the first left behind.

Start again from the two attached files. Ignore every earlier answer, including your own tables and your own code, and do not reuse any variable, dataframe or file handle. Read each file again.

Recompute the eight control figures from the raw files only: the row count of each file; the total of [VALUE_COLUMN] in each file; the total absolute difference in [VALUE_COLUMN] across keys present in both files; the count of keys present in both files; the count present in File A only; and the count present in File B only.

Show the Python used for this pass and state whether it was executed. Print each figure on its own line with a label. Do not compare these figures to anything stated earlier and do not explain any difference. Report the numbers only.

What to check: that the pass ran in a new conversation with both files uploaded again, that the eight figures match the first pass digit for digit, and that the code reads the files rather than a variable created earlier. A difference is not a failure of the tool, it is the control working. Stop and reconcile the methods before touching the exception list.

The exception list, with no cause asserted

The exceptions are the output that matters, and they are the easiest place to overreach. A row that differs by a round figure invites a story about a missed invoice. The files do not show that.

Use only the reconciliation table from the tie out pass, pasted in below, and the two attached de-identified extracts. Write a plain working note for [ORGANISATION] covering the exceptions for [PERIOD].

For each exception give the [ROW_KEY], the value in [SYSTEM_A], the value in [SYSTEM_B], the difference, and the evidence that would be needed to resolve it, named as a document type rather than as a conclusion.

Do not state a cause, a fault or a responsible party. Where the files do not show why a row differs, write "cause not shown in the attached files". Use placeholders for every party and system. Do not introduce any name, employee number or account number that is not already in the attached files.

End with one line: prepared for review by [OWNER], to be reviewed by [REVIEWER], files as at [DATE_CHECKED].

What to check: that no row carries an explanation, that the differences restate the table rather than revising it, and that no identifier has appeared that was not in the uploaded files. An invented account number survives longest, because it looks like a detail somebody must have supplied.

What the record has to show

The method, not just the answer. The Australian Taxation Office's (ATO) overview of record-keeping rules for business, last updated 18 June 2026, lists among the records a business keeps "any documents containing details of any election, choice, estimate, determination or calculation you make for your business's tax and super affairs, including how (basis or method) the estimate, determination or calculation was made". The same page states that most records are kept for five years, that the information in them must not be changed, and that a business must be able to show them to the ATO on request, providing encryption keys and a data extract in a standard format such as Excel or CSV where the records are encrypted.

The statutory anchor is section 262A of the Income Tax Assessment Act 1936, Compilation No. 192, compilation date 1 July 2026, read on the AustLII consolidation as at 25 September 2026, which provides that a person carrying on a business must keep records that record and explain all transactions and other acts engaged in by the person that are relevant for any purpose of that Act. Subsection 262A(3)(a) requires those records to be in writing in English, or readily accessible and convertible into writing in English. Paragraph 262A(4)(a) sets five years from preparation or from completion of the transactions, whichever is later, and the ATO page names further records kept longer.

That is an argument for keeping the code and the two extracts, not the conversation. A chat log is writing, but it is not a stable record of how the calculation was made, and none of the four vendor pages in this set was read for how long a conversation is retained. The same argument runs through tracing the decision rather than the tokens.

Where does this method fail?

In four predictable places, worth naming before the first run.

• Treating a balanced total as proof. It is one condition of a correct reconciliation, satisfied just as neatly by two offsetting errors of equal size.
• Treating the de-identification as finished. A [ROW_KEY], a date and an amount can still identify a person in a small population, and the OAIC guidance runs against any assumption that a stripped file has left the Privacy Act.
• The vendor page moving. Every upload figure above sits on a help page rather than in a commitment. The OpenAI pages carried a relative update label rather than a date, the Microsoft and Google pages no date at all. Check each limit against the tool.
• Language creep in the write-up. The assistant did not check, confirm or verify anything. It computed once, and a working paper saying the tool verified it records something that did not happen.

Do this Monday

Build the reconciliation working paper, one page, before running anything through it.

The owner is the team leader who signs the reconciliation, in finance, payroll or claims. Not the person who runs the prompt or exports the files.

Building the sheet fits in an hour. Its head carries one line each for:

• Reconciliation name
• [PERIOD]
• Each extract name and row count
• De-identification applied
• Assistant and plan used
• [TOLERANCE], in days
• Exception count
• Code file location
• [OWNER]
• [REVIEWER]
• [DATE_CHECKED]

Under it sits the control block, which does the work.

Run the first period through it at the next scheduled reconciliation, using the three prompts above.

The check is that every control figure carries two numbers, that each variance reads zero, and that the code file sits beside the working paper. A variance other than zero means the computations disagree, so stop and reconcile the methods before the exception list is signed. A figure carrying one number means the control did not run.

The bottom line

A two source tie out is the right first assisted task because it is checkable, and it stays checkable only if the sequence is kept. Reduce and de-identify before the upload, ground the model in the two files, demand the code alongside the table, and recompute the control figures in a pass that reuses nothing. The assistant computes an answer once and never checks it, so the second computation is the only evidence the first held. Keep the code and the extracts for at least five years from preparation or from completion of the transactions, whichever is later, because the Australian Taxation Office asks how the calculation was made. This is general information about a working method, not legal, tax or accounting advice.