day-book – Documents & Office skill for AI agents

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 preserves separate book balances and distinguishes them from observed cash counts and statement balances 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 in/out and balance columns are this template's chosen model. 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.

| | Movement row | Day Summary row |

|---|---|---|

| What it is | one receipt or one payment | one per day, written after the day is closed |

| What it books | money, into exactly one book | no money at all - it totals and proves |

| Book Section | the one book it was booked to | All Books |

| Mode | the instrument used | Mixed when the day's instruments differ |

| The six In/Out columns | the amount in its own book, and the other two are not applicable | the day's totals for all three books |

| The six balance columns | brought forward, and the running balance after this entry | the day's opening and closing balances |

| Transaction Reference, Voucher Number, Party | the entry itself | the day's detail set, not a single voucher |

| Duplicate Check | this entry checked against the day's other entries | the whole day's set checked |

| Balance Difference, Reconciliation Status | not applicable - a single movement is not reconciled on its own | the day's break, and the status of it |

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. Keep the calculated/book closing balance unchanged; record the independently observed figure and signed difference separately in Notes. An unexplained difference does not replace the book closing balance. 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 per-book book balance, observed balance and difference in Notes. Always retain all per-book differences: equal and opposite breaks can net to zero and must not be called reconciled.

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. Use exact decimal arithmetic and the confirmed currency's minor-unit/rounding policy. The displayed NUMERIC(14,2) is an illustrative two-decimal assumption, not a rule for every currency; do not sum different currencies or represent missing values as zero.

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 - its build output is an empty template. If a requested review includes supplied transaction data, use only the needed facts and do not reproduce identifiers.

Model limits and validation

The SQL/JSON examples enforce only some structural constraints. Application validation must distinguish row types, selected books, one direction per movement, date/book/currency scope, duplicate references, per-book balance identities and close authorization. Derive Day Summary totals solely from Movement rows; never sum both together. Internal cash/bank/wallet transfers require linked equal-and-opposite movements in the two books, not a new business receipt/expense. Decimal precision, overdrafts, settlement timing and reconciliation cadence require the business's accountant and local rules.

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 again

… (full content is in the download package)