Build something that is not there yet
Produce the trial balance and close pack as code
- The close pack is rebuilt by hand every period and last quarter's trial balance cannot be reproduced as it was when the period closed.
- Auditors ask what a closed period showed at its hard close and whether anything was posted into it afterwards.
- Controllers need the journals posted after the soft close listed, and a hard stop when a closed period changes.
Build the trial balance by account and fiscal period, plus entity and currency where more than one is in scope, with opening, debits, credits and closing, roll it up to statement lines, list late postings and invalid journals, and record each period's state at or after its hard close so any later change to it is handled as the approved lock policy says.
Use this Recipe
Use the Vibedata Recipe `finance-trial-balance-close` at https://github.com/accelerate-data/vibedata-cookbooks/blob/main/recipes/finance-trial-balance-close/recipe.md Read the Recipe and execute it in the context of the current Intent.
Recipe id finance-trial-balance-close · Canonical definition
Verified by
What has to be observably true before this Recipe is finished.
- On a completed run, at each in-scope grain, closing equals opening plus debits minus credits for each account the approved eligibility policy includes, in each in-scope period unless approved semantics omit it; summary accounts add only their members; excluded accounts are listed with reasons.
- On a completed run, per period and balancing grain, eligible monetary debits equal credits, closings net to zero, and statement lines and the balance-sheet identity hold as approved, apart from any approved opening imbalance, flagged journal or excluded-account line, each shown with its amount.
- At each in-scope grain, each period's closing as shown becomes the next period's opening, except at a fiscal-year boundary, where the opening follows the approved year-end treatment, or where an approved flag policy carries a closed-period change forward.
- Each journal lands in the period the approved placement rule gives it; under an approved as-at instant, only lines the approved as-at rule places by then count, and later lines are reported as outside that run.
- Where lines carry a posting instant, journals posted after their entity's soft close, up to its hard close, are listed as late with how late each was at a stated precision, honouring each boundary's approved inclusivity; otherwise lateness is reported as unproven.
- On a completed run, each in-scope line lands once: in the trial balance (flagged if policy includes its invalid journal), on a listed excluded account, excluded with its journal and reasons, or in a recorded-figures flagged period's change detail; each period and grain shows what was left out.
- Where the approved policy fails the run on an invalid journal or on an opening set that must balance, the run fails explicitly and names each offending journal or opening account and its reason.
- Each period's record, per entity where closes differ, is taken as at hard close only where posting instants with kept history or a no-in-place-edit source show no change since; else as first observed after it, labelled so. It survives later builds and refreshes; a reopen keeps the old record.
- A change to a closed period, as the approved definition counts one, is detected against its record; under a fail policy the run fails naming each period and grain, each line where line ids are stable, recorded and current figures, and publishes no close pack.
- Under a flag policy a changed closed period is published visibly flagged with the same change detail; no close-pack output is published from data the closed-period check has not checked, any other route to it is reported unproven, and each published period shows its close status.
- A requested past as-at rebuild counts only lines the approved as-at rule places by that instant, writes no closed-period record, and states that in-place edits or deletions since then cannot be recovered unless the source or kept history carries them.
- Results do not change with the session time zone, each output is unique on its declared grain, and the outcome states what remains open and what the inputs cannot prove.
Recipe promptThe task specification the agent reads. Reference only — it is not what you copy.
Build <trial_balance_model>, <statement_rollup_model>, <late_posting_model>, <invalid_journal_model> and <close_status_model> from <journal_source>, <chart_of_accounts>, <fiscal_calendar> and <close_calendar>. Inherit the semantics the Intent or its approved requirements already establish, and resolve with the user only the semantics they leave open. At the approved grain (account and fiscal period, plus legal entity and currency wherever more than one is in scope), show opening, debits, credits and closing, roll the accounts up to the approved statement lines, apply the approved fiscal-year-end treatment, where lines carry a posting instant list journals posted after the soft close, and list every invalid journal with its reasons. Record each period's state at or after its hard close, keep that record where later builds do not rewrite it, and handle any later change to a closed period as the approved lock policy says. Where the user asks for it, rebuild the trial balance as at a past instant. Keep sources read-only and report what the inputs cannot prove.
Agent guidanceHow the agent approaches the work, and what it will not do.
Inherit the Intent's repository, platform, Domain, sources and every semantic decision its approved requirements already record; do not ask the user to confirm them again. Profile the journal source (journal and line ids, types, periods, accounting dates, posting instants, accounts, debit and credit amounts, reversal links), the chart of accounts with its account types, posting and summary flags, statistical units and statement mapping, the fiscal and close calendars and any opening balances, and check whether posted lines can be edited or deleted in place. Use Ask first only for semantics still open, and record each decision as the user's own answer. Keep the chart, statement mapping, calendars, journal types, openings and the year-end rule explicit, and editable where the approved requirements say so. Keep the closed-period records and any approved reopen records where later builds and full refreshes cannot rewrite them, and never publish close-pack output from data the closed-period check has not checked. The trial balance, the invalid journals and the closed-period checks must never disagree about a line. Report every invalid journal, late posting or closed-period change left open and what the inputs cannot prove.
Composes
- capturing-requirements
- profiling-source-data
- applying-medallion-data-modelling
- generating-dbt-model
- dbt-unit-testing
- running-dbt-in-sandbox
- verifying
Asks first
Semantic decisions the Intent cannot supply. Never context Studio already holds.
- If unresolved, which ledger, legal entities, currencies and periods are in scope, which amount (ledger or transaction currency) is balanced, and does the grain include entity and currency (it must where more than one is in scope)?
- If unresolved, which fiscal calendar applies (year start, period grain, any adjustment period), which field places a journal in a period, and which instant does a run judge against, including rebuilds as at a past instant?
- If unresolved, when does each period soft-close and hard-close, for each entity if they differ, in which time zone, and is a posting exactly at a close instant on time or late?
- If unresolved, which accounts are eligible (statistical, memorandum, consolidation-only, non-posting, summary: in, out or roll-up only, why), each one's type, normal balance and statement line, are zero balances shown, where do openings come from, must they balance, how is a missing one shown?
- If unresolved, how are revenue and expense closed at fiscal-year end (a computed roll into a named, eligible retained-earnings account, or a closing journal already in the ledger), and how are reversals linked to their originals?
- If unresolved, which journal types exist, which journals are invalid, one row per reason or per journal, and is an invalid journal excluded with a visible count, failing the run, or, if it can be placed by account, period and amount, included and flagged?
- If unresolved, what counts as a change to a closed period (own postings, or also carried openings), does it fail the run or flag the period (at recorded or current figures, carried into later openings or not), and can a period reopen, approved by whom, for how long?
- If unresolved, can the source edit or delete posted lines in place, are line ids stable, and does each line carry a posting instant?
Guardrails
- Do not choose the calendar, close instants, account eligibility, year-end treatment, invalid-journal handling or lock policy for the user, and take none from the data or common practice; the user may ask for alternatives or a recommendation.
- Never let a build rewrite a closed period's record except through the approved reopen rule, and never downgrade an approved fail-on-change policy to a warning.
- Never drop or double count a journal line; an invalid journal stays visible with every reason.
- Never default a missing opening balance or amount to zero unless the approved semantics define absence as zero.
- Apply one approved account-eligibility policy to openings, debits, credits, closings, statement roll-ups and completeness; summary accounts may roll up for presentation but never count again as posting balances, and statistical quantities never enter monetary balancing.
- Never net distinct legal entities or currencies together; consolidation and currency translation are separate outcomes.
- Do not infer an edit, deletion or posting time the source does not carry; report it as unproven.
- Stop at the close pack: do not post corrections or closing journals to the ledger, and keep sources read-only.