Close data preparation is the work of pulling ledger, bank, and third-party records into one usable shape before reconciliation begins. It covers format alignment, sign conventions, reference matching, and account mapping across entities and systems.
Most controllers count the close from the morning that reconciliation begins. The days before that point rarely appear in the estimate, even though they often hold the larger share of the calendar. Accounting teams routinely describe half the cycle as getting records into a shape somebody can actually work with.
The stretch has a recognizable rhythm. Someone exports a trial balance, pulls a bank file, waits on a report from a subsidiary running a different system, renames columns so two extracts can sit side by side, and corrects dates that arrived in three formats. None of this calls for professional judgment, though all of it has to happen before an accountant can exercise any.
What makes the step worth attention is its determinism. There is a correct answer for how a date should be formatted, how a currency column should be signed, and which subsidiary account rolls up into the consolidated chart. Verifiable right answers make this the most automatable material in the entire close, and in most organizations the job is still done by hand.
Why the Close Calendar Starts Before the Accounting Does
The published checklist usually begins with reconciliations and ends with financial statements. The lived version starts several days earlier, when a staff accountant assembles source files, and those days are rarely measured.
This matters for a practical reason. A team under pressure to compress the close will reach for the steps it can see, so it standardizes templates and tightens review deadlines, while the unmeasured days at the front stay exactly as long as they were. Those efforts stall because the largest block of time was never on the chart.
The front of the calendar is also where errors enter quietly. A truncated reference number or a mis-mapped account does not announce itself during preparation. It surfaces three days later as a variance nobody can explain, and the investigation then runs backward across every transformation the record passed through.
Fixing a mapping mistake before extraction costs a fraction of what tracing the same problem afterward costs, which is why the quiet hours at the front are worth measuring first.
Where the First Three Days Actually Go
Across several subsidiaries running on more than one general ledger, assembly becomes the single largest consumer of close time. The causes below appear in nearly every multi-entity accounting organization, and none of them is exotic, which is part of why each one keeps adding hours no checklist records.
Formats That Disagree Across Systems
Two systems rarely describe the same transaction identically. Dates arrive as day-month-year in one extract and month-day-year in another. Amounts carry thousands separators in one file and none in the next. Identifiers come padded with leading zeros on one side and stripped on the other.
A person resolves each of these in a minute or two, which is precisely why the cost stays invisible. Multiplied by the number of sources, subsidiaries, and periods, the total becomes a meaningful portion of the calendar.
Sign Conventions and Truncated References
Sign handling is the quieter problem. A credit expressed as a negative in the ledger export and as a positive in a bank statement will tie out only after somebody notices the mismatch, and a reconciliation built on the wrong convention produces a variance exactly twice the size of the item.
Payment identifiers carry a similar trap. Banking systems frequently truncate a reference to a fixed character length, so the string that would have matched the invoice arrives incomplete. The comparison then fails on two records that are, in substance, the same transaction.
Recommended read: Accrual Automation: How Accounting Teams Handle Expenses That Arrive Before the Invoice
The Mapping Tab Built by Someone Who Left
Most accounting teams with more than one ledger run on a mapping file that converts subsidiary accounts into consolidated ones. It holds until the business adds a line, opens an entity, or restructures the chart, at which point whoever inherited the workbook has to reverse-engineer logic nobody documented.
This is the five-tab spreadsheet problem wearing different clothes. The institutional knowledge sits in a worksheet instead of a written standard, and the close depends on it either way. For teams already carrying too much of the month in Excel, that dependency is worth auditing directly.
Deterministic Work Has a Right Answer
Preparation differs from the rest of the cycle in one important respect. Nearly everything else rests on a judgment call: is an invoice expected or already received, does a balance treatment follow what happened last period, is a variance explainable by something a reviewer would accept. The front-end work asks only for correctness.
That distinction is what puts the step within reach of execution. An accounting agent normalizes formats, applies the sign convention each source uses, resolves truncated identifiers against a secondary field, and maps every line to the consolidated chart. The output is a standardized, mapped dataset ready for the close to begin.
The boundary matters as much as the capability. Software that cannot resolve an identifier against any secondary field does not invent a match, it escalates the item with the records it compared, so unresolved exceptions arrive as a reviewable list on day one instead of surfacing a week later as an unexplained difference.
One condition governs everything Nominal deploys. The procedure has to be written down. A team that has never recorded how a subsidiary extract becomes a consolidated trial balance usually finds the writing to be the harder half of the project, and worth doing regardless of what runs afterward.
If the logic converting local accounts into consolidated ones lives in a spreadsheet instead of a documented standard, that is a signal worth reading.
How Agents Prepare Close Data Before the Accounting Starts
Nominal's agents connect at the data layer through a normalized model, which is how records from a general ledger, a bank, a CRM, and third-party extracts arrive in one consistent structure. Older on-premises systems participate on the same terms, since the integration sits below the application interface instead of depending on a modern one.
A Deployed Finance Engineer encodes the preparation procedure the accounting team already follows, including the mapping rules, the sign convention each source uses, and the fallback logic for a primary identifier that truncates. The encoded version then runs every period, escalating anything outside it instead of guessing at a treatment nobody specified.
The result arriving on day one is a dataset the team did not assemble by hand. From there, the same environment carries the work forward, which is where agentic reconciliation and the rest of the close automation sequence begin.
What the Accounting Team Still Owns
Judgment stays where it belongs. Deciding that a newly opened entity maps into a particular consolidated account calls for an accountant, and so does confirming that a sign convention reflects how the business reads the balance. Software applies those calls consistently without making them.
Oversight is unchanged as well. Every transformation is visible and attributable, so a reviewer can see which rule touched which line and why, instead of trusting that a file arrived correct. The same record makes a later variance investigation finite, because the path from source export to prepared dataset can be reconstructed rather than remembered.
What changes is the shape of the first week. The staff accountant who spent three days assembling source material spends them on the accounts that genuinely need one, and the close starts where the checklist always claimed it did. A calendar measured from that point reflects something closer to the real cost.
Book a demo to see what a prepared dataset looks like against your own entity structure.
About the writer
