Day Book

Day Book

What it is: The daily cash, bank and digital receipt-and-payment record, with a day-end control row that reconciles the day before it is closed.

Overview

Works out the smallest useful Day Book setup for the business in front of it, then builds it only when asked. The default output is a short recommendation, not a spreadsheet. Artifacts - CSV, SQL DDL, JSON Schema, Notion mapping - are produced on request, from one field list so they cannot drift apart.

Layer: Layer 4: Cash. Fits: Starter stage. Table code: n/a.

Before anything is generated, the design is checked against itself. A day book is the easiest table in the pack to write badly, because the same column can mean two different things on two different rows and neither reading looks wrong on its own. So before emitting any artifact:

• Look for conflicts in the rules, the examples, the field definitions, the row meanings and the output formats. Where the design, the examples or the business's existing sheet disagree with each other, do not reproduce them as they stand.
• Name the conflict out loud, then resolve it with the simplest accounting-safe interpretation. The simplest safe reading of a disputed field is the one that keeps cash equal to the bank position and never invents a movement to make a total look right.
• Derive CSV, SQL DDL, JSON Schema and the Notion mapping from one field model afterwards, so that no field exists in one artifact and is missing or differently defined in another.

The rule this table exists to enforce: the debit/credit presentation of a day book depends on the software's day-book format. It is not a universal rule that all receipts are debit and all payments are credit - some books present receipts on the payment side, some carry both columns, some carry neither. So this table does not hardcode a Debit/Credit pair. Debit/Credit Presentation is a text field that records the presentation as configured in the business's own software, and the six in/out amount columns plus the six balance columns are the part that is universal. Where a book labels its columns Dr and Cr, that label is what goes into Debit/Credit Presentation; nothing in this table decides which side a receipt sits on.

Two row types, and they are not the same kind of thing. Row Type says which one a row is, and the two are read differently.

What each balance field means. Every one of the six balance fields is a balance, never a movement. Opening Cash Balance, Opening Bank Balance and Opening Digital Balance are what was brought into the day. Cash Closing Balance, Bank Closing Balance and Digital Closing Balance are what was left at the end of it. The identity that connects them, per book, is:

opening balance + money in - money out = closing balance

On a Day Summary row that identity must hold separately for cash, for bank and for digital. On a Movement row, the opening balance is what was brought forward into that entry and the closing balance is the running balance after it, in that entry's own book only.

The identity that carries the day forward. A day's opening balance is not a fresh number. It is the previous day's closing balance for the same book. So the check that closes a day is:

previous day's closing balance + today's movement = today's closing balance

Where it does not hold, the difference goes in Balance Difference - signed, and not spread across the books - and Reconciliation Status is set to Needs Review or Unreconciled. The component is never edited to make the row tie. A day book whose balances are adjusted until they agree records nothing about the business.

Balance Difference and Reconciliation Status. Balance Difference is the total unexplained difference across the three books on that row: negative where the book is above the counted or agreed figure, positive where it is below. Where a difference is confined to one book, write which one in Notes with both figures, because one column cannot hold three breaks. Reconciliation Status is the worst of the three books, never the best. A bank balance that agrees does not make a cash count that does not agree reconciled.

A day is not Done while the cash count or the bank position is unreconciled. Neither is it Done while Duplicate Check is Not Checked, or Reconciliation Status is anything other than Reconciled, or while an entry is Blocked. Entry Verified is the workflow status (Not started | In progress | Blocked | Done | Cancelled) and it moves to Done only when the control row for that day is clean, or when a human has reviewed and accepted a recorded difference.

Money, dates and rounding. Amounts are the gross amounts that actually moved, exactly as recorded in the business's books, tax-inclusive where the entry was tax-inclusive. This module does not split tax out of a movement. Money is a bare number with no currency symbol in the cell, and the currency itself is Unknown until the user states it. Dates are ISO YYYY-MM-DD in real date fields. Round once, at the end, to two decimal places, so the day's components re-derive the day's totals.

When to Use This Skill

• day book
• daily cash and bank book
• cash book and bank book
• daily receipts and payments register
• end-of-day balance check
• petty cash day sheet

Also use it when the user says "the daily cash, bank and digital receipt-and-payment record, with a day-end control row that reconciles the day before it is closed", or describes the same process happening in a spreadsheet, a document or someone inboxes.

Do not use it for: making payments, recording receipts in detail, tax filing, or legal advice. This skill produces empty templates only - it never holds or processes real transaction data.

How It Works

Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

Step 1 - Identify intent

Read the request and pick the intent before asking anything.

• "set up" or "build" or "create" -> the user wants artifacts; go to Step 2.
• "our process is ..." or "it is in a sheet" -> import or fix; capture what is there, then Step 2.
• "is this right" or "review this" or "audit this" -> review; answer from what they share and do not rebuild anything.
• "show me the movement" or "where did the cash go" -> report; answer from what they share.
• "how do I ..." -> advice question; answer directly and offer the build only if it helps.

If the intent is already clear from the request, do not ask the user to repeat it.

On a review, check the design against itself before checking the numbers: the rules against the examples, the field definitions against the row meanings, and the four artifacts against each other. Report the conflicts and the simplest accounting-safe reading of each, then report the control gaps - an unreconciled balance with no difference field, a Done day with an open cash count, a hardcoded Debit/Credit rule. Do not rebuild the book because a review was asked for.

On a fix, preserve every valid fact already in the book, name each contradiction, correct the model, and keep the change to the minimum that makes it consistent. Rebuild the artifacts only when the fix request asks for them.

One message, one question, no batching. Open with the question that decides which columns exist:

Q: Which books do you keep separate in the day book - cash, bank, or a digital wallet?

Step 2 - Ask only what is missing

Treat ambiguous replies as unanswered and ask which explicit option the user means. Record unknown values as Unknown; Unknown is not zero. A record must not be Done when a required check fails.

Skip anything the user already answered, in any earlier message. Ask the rest one at a time, and stop as soon as the remaining answers would not change the recommendation or the requested artifact. Never batch two questions into one message.

• Books - Cash, bank and digital all separate? Which software or format is the book kept in? Entries made daily or weekly?
• Entries - Who writes them? From vouchers, or from the bank feed? Same day or the next?
• Day-end control - What is actually checked at day end? Is the cash counted? Is the bank position agreed, and to what? Who signs it off?
• Open items - Digital wallets that settle late? Known duplicate patterns? How is a difference handled when it appears?
• Outcome - What do you need? The daily book, the day-end reconciliation record, or both?

An ambiguous answer is not an answer. yes, no, maybe, same, okay and fine do not answer a multiple-choice question. Re-ask as an explicit choice:

Q: Which do you mean: a count of the cash drawer or the balance your bank statement shows at close?

A partial answer keeps only the part that was answered. "We check it monthly, and the cash on Fridays" records the frequency and leaves the digital-wallet position Unknown.

Never invent a business fact. Not an amount, a balance, a date, a voucher number, a bank reference, an account number, a mode, a book section, a reviewer name, a status or a difference. If a value was not supplied by the user or derived by a documented formula from supplied data, it is Unknown or blank. Never turn Unknown into zero - a blank says the count has not been done, a zero says the drawer is empty. Record Unknown, move on, and never re-ask an unknown the user has already said they do not have.

Where the count or the statement has not been seen, the day's Balance Difference is blank and Reconciliation Status is Unknown. It is not zero, because a zero difference is a claim that the money was counted and agreed.

Step 3 - Hold the internal context

Hold the answers in this shape. It stays internal - it is not shown to the user unless they ask, and it never carries a value the user did not give.

module: day-book
intent: null            # setup | advice | review | fix | build | convert | export
scale: null             # Starter | Growth | Scale, only if the answer changes it
areas:
  "Books": null
  "Entries": null
  "Day-end control": null
  "Open items": null
  "Outcome": null
books: null             # which of cash | bank | digital are kept separately
book_format: null       # the day-book format of the software in use
debit_credit_presentation: null
cash_counted_daily: null
bank_agreed_to: null     # statement, feed, or neither
sign_off: null
late_settling_wallets: null
known_duplicate_pattern: null
difference_handling: null
requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
confirmed_facts: []     # only what the user actually said
unknowns: []            # asked and not answered
open_questions: []      # the unanswered ones, in the order worth asking