The AI Data Readiness Checklist for Finance Teams (It's Just Reconciliation)

Every vendor selling AI into finance now publishes some version of a “data readiness” checklist. Consolidate your sources. Clean your chart of accounts. Standardize your naming. The framing is almost always the same: do this prep work so the AI can understand your data.

That framing is backwards, and it costs finance teams real time. The work on these checklists is not AI prep. It is reconciliation: the same discipline controllers have run every close for decades, for reasons that have nothing to do with language models. The only thing AI changes is how fast a gap in that discipline becomes visible, and how expensive it is to find out the hard way. Here is the checklist, without the AI marketing wrapped around it.

Consolidate your sources into one ledger of record

If revenue lives in QuickBooks, a separate number lives in a sales-ops spreadsheet, and a third version sits in a board deck someone built by hand last quarter, you do not have a data problem an AI tool will surface for the first time. You have had three versions of revenue for as long as those three artifacts existed. A human reconciling the close by hand would eventually notice the gap, ask around, and patch it with tribal knowledge: which tab is “the real one,” which export is stale. An AI has none of that tribal context. It will pick a source and answer with total confidence, and nothing about the interface will tell you it guessed wrong.

The fix is not a new tool. It is the same fix reconciliation has always prescribed: designate one system as the ledger of record, treat every other spreadsheet as a working draft that must tie back to it, and stop letting “the deck” or “the export” quietly become an alternate source of truth. Do this and you have not made your data AI-ready. You have made your close defensible, which is the actual goal: AI just makes the absence of it obvious faster.

Audit your chart of accounts for drift

Charts of accounts rot slowly. A new AP clerk creates “Office Supplies - Misc” instead of using the existing “Office Supplies” account. A department head starts booking software spend under “Consulting” because that account happened to be open in a dropdown. Two years later you have four accounts that all mean roughly the same thing, and nobody remembers which one is authoritative for which vendor.

A human analyst catches some of this by memory and pattern-matching during variance review. An AI system asked “what did we spend on software last year” will sum only the account it was told to sum, missing the drift entirely, or worse, silently including an account that shouldn’t be in scope. Run an account-drift audit: pull every account with activity in the last 12 months, group by apparent purpose, and consolidate or map duplicates before they compound further. Chart of accounts hygiene has been a close best practice since long before anyone pointed an LLM at the ledger: it just used to fail quietly instead of confidently.

Standardize vendor and customer naming

“Amazon,” “Amazon.com,” “AMZN Web Services,” and “Amazon Web Svcs” can all show up as distinct vendor names in the same AP system, each with its own transaction history. A controller doing a manual roll-up learns to recognize the variants. A matching engine (human or automated) that treats them as four separate vendors will misstate concentration, understate total spend with any one counterparty, and break any analysis that groups by vendor.

This is a normalization problem reconciliation teams have solved for years with vendor master files and dedupe passes before month-end close. The checklist item is the same one it always was: run a fuzzy-match pass on your vendor and customer master data, merge duplicates, and enforce a naming convention on new entries going forward. See how numbers get normalized for what that normalization step looks like once it’s automated rather than done by hand each close.

Tag dimensions consistently

Department, cost center, region, product line: these dimensions only work as filters if every transaction that should carry a tag actually carries the right one. A single untagged or mis-tagged batch of transactions doesn’t just create one wrong number. It silently breaks every downstream report that slices by that dimension: the departmental P&L, the regional forecast, the product-line margin analysis, all quietly wrong in the same direction.

Dimension gap	What it silently breaks
Missing cost center on a batch of journal entries	Departmental P&L totals, budget-vs-actual by team
Region left blank on a subset of invoices	Geographic revenue splits, entity-level consolidation
Product line inconsistently applied pre/post a rename	Product margin trends, any multi-period comparison
Inconsistent intercompany tagging	Consolidation eliminations, entity-level reporting

None of this is new. It is the same tagging discipline that data contracts between close stages have always required: see data contracts between stages for how that discipline gets enforced structurally rather than left to individual diligence.

Decide a currency and rounding convention, and write it down

If your entities transact in more than one currency, someone has already made decisions about which rate to use for translation, how to handle rounding at the transaction versus the summary level, and how to treat FX gains and losses in consolidated reporting. The problem is that these decisions often live in one controller’s head, or in a footnote in last year’s audit workpapers, rather than in a documented convention every system and every person applies the same way.

Undocumented conventions are fine when one person owns every calculation. They break the moment more than one system (human, spreadsheet, or AI) is producing numbers against the same ledger, because each will quietly default differently. Write the convention down: which rate source, which rounding rule, which treatment for realized versus unrealized FX. This is not new work invented by AI adoption. It is the kind of documentation any new hire onboarding onto your close process needs on day one: see onboarding a new team member in their first week for what that documentation typically has to cover.

Why this checklist isn’t really about AI

Look back over the five items: one ledger of record, a clean chart of accounts, deduplicated vendor and customer names, consistent dimension tags, a documented currency convention. Every one of them is a reconciliation control. None of them mentions a model, a prompt, or a vector database. That’s the point.

AI does not need special data. It needs correct data, presented consistently, tied to a source: which is exactly what a well-run close has always required. What AI changes is the cost of skipping this work. A human analyst doing manual reconciliation will eventually stumble on a duplicate vendor or a stale account and flag it, because humans notice friction. An AI system asked to summarize the same data will not stumble. It will compute a confident, wrong answer and hand it to you with no visible seam, because nothing in the interface distinguishes a clean number from a dirty one. The checklist doesn’t get longer because you added AI. The consequence of skipping it gets faster and quieter.

If your intake process already classifies and structures incoming documents before they hit the ledger, several of these items get considerably easier: see document intake and classification for how that stage reduces the manual cleanup at source.

The takeaway

There is no separate species of “AI-ready” financial data. There is reconciled data and unreconciled data, and AI simply exposes which one you have faster than a quarterly close cycle used to. Run the five items above (one ledger of record, a clean chart of accounts, deduplicated names, consistent tags, a documented currency convention), not because a vendor told you to prepare for AI, but because they are the same controls that make any close defensible, with or without a model reading the output.

If you want to see what it looks like when this reconciliation work is enforced structurally rather than left to a checklist someone runs once a year, book a demo.