Use AI to reconcile monthly reports across CSVs
Follow recorded prompts, responses and revisions across 20 rows, verify a complete report, then reuse the process on new November data.
About 45 min readingAs of Oct 2026
Lesson guide · goals & preparation
By the end of this guide
- Supply files, column meanings and rules to obtain inspectable decisions and a report.
- Apply new corrections in the same conversation and verify both changed totals and preserved records.
- Reuse the request in a fresh month and check it with independent arithmetic.
Who this is for
- People combining departmental tables into recurring reports.
- Readers who want to verify AI-generated totals.
What you need
- The foundations on evidence and comparison are helpful.
- Tool use is optional; sources, recorded responses and answers are included. Paste CSV text if attachments are unavailable.
This lesson’s terms, in plain language
Read the short meanings here. Open a term for a fuller explanation and example.
This reading lesson explains how to use external AI tools. Read from theory to the workflow, examples and explanations, or use the contents to jump to a section.
1 / 4
Theory
Understand what to ask AI to do, how to ask, and the ideas behind the workflow.
Ask AI for the decisions behind a monthly total
Imagine asking an assistant to total two departmental CSV exports. A single number hides decisions about duplicates, blanks and cancellations. Here you request a row-decision table, an accepted ledger and a report, so each conclusion remains inspectable.
The workflow to understand is: Define columns and reporting period → state duplicate and missing-value rules → request row decisions and a draft report → verify totals against sources → revise with corrections. First learn why each input and constraint matters, then study the requests, finished examples and explanations. This is a reading lesson about external AI tools; no account or runtime is required.
A CSV is a table stored as text: lines are records and separators divide fields. An assistant can explain columns and combine records, but receiving a file does not prove that every row was read or that arithmetic is correct. Ask it to report filenames and row counts before accepting the summary.
The fictional stationery wholesaler has two October exports and a correction ledger. Even the later October and November dates are invented teaching data, not future transactions. This is an exercise in applying stated rules, not an accounting close or tax determination.
On October 28, 2026 we sent the material to Claude Sonnet 5.5 with tools disabled, then added a correction in the same conversation. Quoted responses are unchanged extracts from that run. Separately calculated tables are marked as editorial verification; your assistant may use different wording.
To try it, open a new chat and paste the request and CSV text. Attach CSVs if your tool supports them; otherwise copy their text. All important inputs, outputs and explanations are included here, so an account or payment is optional.
Prepare the files and the rules the assistant must follow
The first export has 12 rows A01–A12; the second has 8 rows B01–B08. source_row locates a record, while invoice_id identifies the transaction. Keeping both avoids confusing exclusion of a duplicate row with cancellation of the transaction itself.
Figure: Several tables merge into shared columns while duplicate and missing rows stay identifiable · AI Ping Appending means stacking comparable records. Microsoft's Power Query documentation describes matching headers rather than column positions. State the column meanings too: all amounts are KRW, refunds are negative, and reporting uses transaction month rather than export date.
A03 and B01 repeat O103. A04 and B02 both identify O104 but disagree at 60,000 and 65,000. The shared ID detects a conflict; it does not resolve it. Ask for conflicting values to be held until the correction ledger supplies evidence.
A05 has an impossible day 32 and A06 has a blank amount. Guessing day 31 or replacing the blank with zero would hide uncertainty. L1 and L2 establish October 23 and 110,000; without them, hold the records.
The 20 rows below and four corrections in the next section are the complete initial input. The download contains identical CSVs and column notes. Preserve originals and label the conversation October v1 so later evidence remains distinguishable.
All 20 fictional October source rows; blank means unknown Source row Invoice Date KRW amount Status A01 O101 2026-10-01 120000 confirmed A02 O102 2026-10-02 80000 confirmed A03 O103 2026-10-03 150000 confirmed A04 O104 2026-10-05 60000 confirmed A05 O105 2026-10-32 90000 confirmed A06 O106 2026-10-09 — confirmed A07 O107 2026-10-12 50000 pending A08 O108 2026-10-15 70000 confirmed A09 O109 2026-09-30 40000 confirmed A10 O110 2026-10-18 30000 confirmed A11 O111 2026-10-20 -20000 refund A12 O112 2026-10-22 130000 confirmed B01 O103 2026-10-03 150000 confirmed B02 O104 2026-10-05 65000 confirmed B03 O113 2026-10-24 90000 confirmed B04 O114 2026-10-25 200000 confirmed B05 O115 2026-10-27 100000 confirmed B06 O116 2026-11-01 180000 confirmed B07 O117 2026-10-28 40000 confirmed B08 O118 2026-10-30 70000 confirmed
2 / 4
Step-by-step use
Learn what to prepare, how to request help and how to revise the result through examples and explanations.
Copy a request that asks for decisions and a complete report
Request four outputs in order: decisions for every source row, the accepted ledger, separate positive/refund/net totals, and a finished report. Starting with prose can hide an unverified calculation; intermediate tables make it inspectable.
The Korean prompt translates the English request used in the recorded run. The English version and downloaded execution record preserve the original. Both include complete data, avoiding a common mistake: copying an instruction that refers to material you never supplied. With attachments, retain filenames and row counts.
Corrections have IDs: L1 fixes O105's date, L2 fills O106's amount, L3 cancels O108 and L4 resolves O104. Ask for both source-row and correction IDs, not merely a polished replacement table.
After generation, inspect coverage before requesting shorter wording. Check all 20 rows, the pending exclusion and the negative refund. The actual assistant added a cancelled label because the requested categories omitted it. A useful explanation matters more than forcing that case into the wrong label.
If an answer stops halfway, ask it to identify its last processed row and continue. A claim to have read everything is weaker evidence than a complete ID list, accepted invoices and exclusion reasons. You can apply the same checks to the recorded response without running a tool.
Correction ledger supplied with the request Evidence Invoice Confirmed change L1 O105 transaction_date = 2026-10-23 L2 O106 amount_krw = 110000 L3 O108 status = cancelled L4 O104 amount_krw = 60000; B02 transcription error Example prompt All data are fictional public teaching data. Use only supplied records. Report by transaction_date month, KRW, confirmed and refund records only. Deduplicate invoice_id; if fields conflict, hold until a correction ledger resolves them. Blank amount is unknown, not zero. Invalid dates need evidence. Keep source_row and correction IDs in each decision. Never alter or publish source files. TASK: Prepare October 2026 reconciliation. Return (1) row decisions for all source rows with accepted/duplicate/conflict/outside-period/pending and evidence (2) accepted ledger (3) count, positive total, refunds, net (4) a short Korean report and an English counterpart. Explain limitations. Do not create code or call tools. [export-a] source_row,invoice_id,transaction_date,amount_krw,status A01,O101,2026-10-01,120000,confirmed A02,O102,2026-10-02,80000,confirmed A03,O103,2026-10-03,150000,confirmed A04,O104,2026-10-05,60000,confirmed A05,O105,2026-10-32,90000,confirmed A06,O106,2026-10-09,,confirmed A07,O107,2026-10-12,50000,pending A08,O108,2026-10-15,70000,confirmed A09,O109,2026-09-30,40000,confirmed A10,O110,2026-10-18,30000,confirmed A11,O111,2026-10-20,-20000,refund A12,O112,2026-10-22,130000,confirmed [export-b] source_row,invoice_id,transaction_date,amount_krw,status B01,O103,2026-10-03,150000,confirmed B02,O104,2026-10-05,65000,confirmed B03,O113,2026-10-24,90000,confirmed B04,O114,2026-10-25,200000,confirmed B05,O115,2026-10-27,100000,confirmed B06,O116,2026-11-01,180000,confirmed B07,O117,2026-10-28,40000,confirmed B08,O118,2026-10-30,70000,confirmed [corrections] evidence_id,invoice_id,field,value,reason L1,O105,transaction_date,2026-10-23,Receipt date confirmed; raw day 32 is invalid L2,O106,amount_krw,110000,Missing amount confirmed from fictional receipt L3,O108,status,cancelled,Order cancelled before recognition L4,O104,amount_krw,60000,A04 amount confirmed; B02 has a transcription error
Check the recorded response against a complete accepted ledger
The first run returned 14 accepted transactions, positive total KRW 1,270,000, refunds −20,000 and net 1,250,000. It covered every source row and resolved O104 to 60,000 using L4. Independent CSV calculations agreed. One successful example does not establish general model reliability.
The first answer paragraph below is an unchanged response extract. The ledger underneath is the editor's independently checked table. Trace A05 through L1 and A06 through L2; do not count B01 and B02 again.
The assistant also noted future-dated fictional rows, the absent original transaction for the refund and possible changes to pending records. This teaching case assumes a completed fictional month. A real interim report needs an explicit cutoff. Changing that rule can change the correct answer even when the file stays the same.
Simply summing nonblank raw amounts gives 1,695,000, not 1,250,000. Explain the 445,000 difference through duplicate exclusion, the 110,000 correction and the pending, cancelled and out-of-period records. A smaller total is not automatically safer or more correct.
For your own work, retain the rules and evidence table alongside the reader-facing report. Do not present these fictional amounts as actual performance. Keeping a summary and an audit table separately makes later AI revision requests precise.
Worked example & explanation Unchanged Claude Sonnet5.5 response extract · 2026-10-28
Example responseA teaching example of a workflow in an external AI tool. Results vary with the request and context.
For October 2026, 14 transactions are accepted (13 confirmed, 1 refund). Confirmed positive total is KRW 1,270,000, refunds are KRW -20,000, and net is KRW 1,250,000. Two duplicates (B01, B02) were excluded. The O104 amount conflict was resolved to A04's KRW 60,000 under correction L4. The invalid date (A05) and blank amount (A06) were fixed using evidence L1 and L2. A07 (pending), A08 (cancelled per L3), and A09 and B06 (outside the period) are excluded. Source files were not altered or published.
Independent editorial verification: 14 accepted invoices Invoice Source KRW amount Correction O101 A01 120000 — O102 A02 80000 — O103 A03 150000 — O104 A04 60000 L4 O105 A05 90000 L1 O106 A06 110000 L2 O110 A10 30000 — O111 A11 -20000 — O112 A12 130000 — O113 B03 90000 — O114 B04 200000 — O115 B05 100000 — O117 B07 40000 — O118 B08 70000 — Revise in the same conversation when new evidence arrives
Now correction L5 says O115 was cancelled before recognition. The initial input did not contain that fact, so the earlier answer was not necessarily wrong. Add evidence in the same conversation and retain separate versions.
Illustration: twenty rows reconcile to fourteen records, then thirteen after cancellation L5 · AI Ping Instead of 'do it again', specify the affected invoice and request before/after counts, positive total, refunds and net while preserving other decisions. Conversation history helps, but it does not replace a precise change request.
We resumed the original session. Claude excluded B05/O115 and returned 13 accepted transactions, positive 1,170,000, refunds −20,000 and net 1,150,000. Check that it removed the transaction once rather than both excluding it and adding a second refund.
The recorded report says other decisions are unchanged. Verify that assertion against the remaining 13 IDs. Revision can introduce unrelated changes, so a concise before/after table is more useful than an entirely regenerated ledger without explanation.
Save original files, L1–L4, response v1, L5 and response v2. A single overwritten report loses the reason for the 100,000 change. Copying text is sufficient; sending mail or changing shared files is not part of this exercise.
Example prompt Same fictional October case. New signed correction L5: O115 was cancelled before recognition; its previously accepted KRW100000 must be excluded. Update the report and give before/after totals, the affected source row and evidence ID, and everything that stays unchanged. Return Korean then English. Do not claim a previous mistake if the original records supported it.
Worked example & explanation Unchanged extract from the follow-up in the same conversation
Example responseA teaching example of a workflow in an external AI tool. Results vary with the request and context.
The October 2026 reconciliation is updated for L5. Accepted transactions number 13 (12 confirmed, 1 refund). Confirmed positive total is KRW 1,170,000, refunds are KRW -20,000, and net is KRW 1,150,000. Under L5, B05 (O115) was cancelled before recognition, so its earlier KRW 100,000 is excluded. All other decisions are as before.
Check AI-generated work in three directions before using it
Asking the same assistant to 'double-check' can repeat the same mistake. First trace inputs forward: every row must have a decision. Version 2 partitions 20 rows into 13 accepted, 2 duplicates, 2 outside the period, 1 pending and 2 cancelled.
Figure: Original and corrected tables sit side by side with changed rows and totals inspected · AI Ping Second trace outputs backward. Net 1,150,000 must come from the accepted ledger; its 110,000 entry must trace to A06 and L2. This catches invented transactions. Ask for mappings, then inspect key examples yourself.
Third compare totals with exclusions. Positive 1,170,000 plus refunds −20,000 equals 1,150,000. Cancelled O108/O115 and pending O107 are absent. Our verification files recompute from CSVs instead of copying the assistant's totals into another table.
Distinguish invalid dates from valid dates outside the month. A09 and B06 belong to September and November; they should not be repaired into October. A05's impossible day 32 genuinely needs L1. Different exclusion reasons imply different next actions.
Record the checks performed, such as all 20 row decisions, L4 for O104, refund sign and O115-only revision. Style can be polished afterward. An unresolved source conflict or missing amount should remain unresolved when the report is passed along.
3 / 4
Check & explain
Think about what you would ask AI, then read the explanation. Written submissions and external AI use are optional.
This is a learning check, not a test you must pass. Use the explanations to understand the ideas.
Q1A04 and B02 share an ID but differ at 60000 and 65000. What do you ask if AI simply keeps the first?
Write your thoughts (optional)
Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.
Read the answer and explanation
Ask it to flag the conflict and cite L4 for accepting 60000 and excluding B02. An accidentally correct choice without evidence is not a reliable process. These are fictional values.
This is your own review, not an automatic score.
Q2L5 cancels the 100000 O115 transaction after net 1250000 was reported. How should the same chat be revised?
Write your thoughts (optional)
Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.
Read the answer and explanation
Specify B05/O115, request a before/after table and preserve other decisions. Net becomes 1150000 across 13 accepted records; refunds remain −20000. L5 was new evidence, not proof the first answer was wrong.
This is your own review, not an automatic score.
Q3AI changes A09 from September 30 to October 1 to include it. Why is that wrong, and how do you repair it?
Write your thoughts (optional)
Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.
Read the answer and explanation
A valid date outside the reporting period is not an invalid date. Restore it, classify it outside-period and update both totals and prose. This differs from correcting invalid A05 using L1.
This is your own review, not an automatic score.
Q4Using only the eight November rows and NL1, identify accepted IDs, three exclusions and net. How should the CSV handle a positively labeled refund?
Write your thoughts (optional)
Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.
Read the answer and explanation
Accept N201, N202, N203, N205, N207. Exclude duplicate N03, outside-period N05 and pending N07; 500000−30000=470000. A prose refund magnitude may be positive, but the signed CSV must retain −30000.
This is your own review, not an automatic score.
Common mistakes
- Requesting only a total without row decisions.
- Replacing unknowns with zero or choosing the first conflicting row.
- Calling a copied AI result an independent calculation.
Your learning record
Completion is optional. Mark this lesson when you feel ready, or move to the next lesson without marking it.
Completion is saved in this browser.
4 / 4
Apply to your work
Consider how new material changes the workflow and checking criteria. Trying an external AI tool is optional.
Try it: reuse the request with November files in a new chat
Use a new conversation for the eight November rows. Reuse the rules, but supply the new month and files explicitly. 'Do it like last month' risks carrying October facts into a different case.
N02/N03 duplicate N202; N05 is a valid October date outside November; NL1 resolves N06 at 120,000; N07 remains pending; N04 is a negative 30,000 refund. Before opening the answer, list expected exclusions from the complete table below.
The fresh session accepted N201, N202, N203, N205, N207 and returned positive 500,000, refunds 30,000 and net 470,000. It displayed the refund as a positive magnitude labeled 'refund'. That is readable prose, but the computational CSV must retain −30,000 under our signed-amount convention.
If your result differs, do not command the model to make the total 470,000. Ask it to inspect the N06 correction, N202 duplicate and N203 sign. Supplying the target number would hide whether the process works on new material.
Save source, rule-bearing request, raw response and independent verification together. Reusing that package is the transferable skill. New currencies or changed refund rules require a revised specification, and a learning-complete mark does not approve a business report.
Fresh check: 8 November rows; NL1 confirms N205 at 120000 Source Invoice Date Amount Status N01 N201 2026-11-02 210000 confirmed N02 N202 2026-11-03 90000 confirmed N03 N202 2026-11-03 90000 confirmed N04 N203 2026-11-04 -30000 refund N05 N204 2026-10-31 50000 confirmed N06 N205 2026-11-07 — confirmed N07 N206 2026-11-08 60000 pending N08 N207 2026-11-10 80000 confirmed Example prompt All data are fictional public teaching data. Use only supplied records. Report by transaction_date month, KRW, confirmed and refund records only. Deduplicate invoice_id; if fields conflict, hold until a correction ledger resolves them. Blank amount is unknown, not zero. Invalid dates need evidence. Keep source_row and correction IDs in each decision. Never alter or publish source files. NEW CASE: independent November 2026 report, not October. Apply the rules to these new rows. Return accepted invoice IDs, each exclusion, positive total/refund/net, and a Korean+English report. [unseen] source_row,invoice_id,transaction_date,amount_krw,status N01,N201,2026-11-02,210000,confirmed N02,N202,2026-11-03,90000,confirmed N03,N202,2026-11-03,90000,confirmed N04,N203,2026-11-04,-30000,refund N05,N204,2026-10-31,50000,confirmed N06,N205,2026-11-07,,confirmed N07,N206,2026-11-08,60000,pending N08,N207,2026-11-10,80000,confirmed [corrections] evidence_id,invoice_id,field,value,reason NL1,N205,amount_krw,120000,Fictional receipt confirms missing amount
Worked example & explanation Unchanged extract from the fresh conversation
Editorial check: the computational CSV retains the refund as-30000.
Example responseA teaching example of a workflow in an external AI tool. Results vary with the request and context.
For transactions dated November 2026, only confirmed and refund records in KRW were counted. Accepted invoices are N201, N202, N203, N205 and N207. Confirmed revenue is KRW 500,000, refunds are KRW 30,000, and net is KRW 470,000. Excluded: the duplicate N202 row (N03), N204 (N05) because it is dated in October, and N206 (N07) because it is pending. N205 (N06) had a blank amount, which was resolved at KRW 120,000 by correction NL1, backed by the fictional receipt.
Write a note (optional)
Use this only if you want to record a prompt or your understanding. This is a notebook, not a connected AI assistant.
Your writing is not sent anywhere. It disappears when you leave or reload this page, so copy anything you want to keep.
References
- Append queries — Microsoft Learn
- Working with duplicate values — Microsoft Learn
- Upload files to Claude — Claude Help Center
