Integer minor units, never floats. Decimal places come from the currency, so JPY renders none and BHD renders three. Nothing is rounded in a table, and nothing is abbreviated in a row that gets reconciled.
Summing across currencies throws, rather than returning a plausible wrong numberYour agent has never handled money before.
It writes good code and a payouts screen that abbreviates amounts, drops currency codes, and reports a failure with no reason. Daybook is the design system and the domain rules — installed together, so every screen your agent writes after it is right about money.
Payout run
Fold Type Foundry's linked account was closed on 9 Aug 2026. Add a new account to retry this payout. Something went wrong. Please try again.
Batch
Filtered to this run| Recipient | Account | Amount | Status |
|---|---|---|---|
| Nordwall Studio Ltd | •••• 4419 4539 8821 0044 4419 | USD 2,400.00 $2.4k | Pending since 2026-08-14 |
| Kettle & Co. | •••• 2073 6011 4429 8830 2073 | EUR 3,120.00 $3,120.00 | Pending since 2026-08-14 |
| Sakura Kōbō KK | •••• 9902 3782 8224 6310 9902 | JPY 480,000 $480,000.00 | Pending since 2026-08-15 |
| Aria Health | •••• 5510 4024 0071 2255 5510 | USD 12,300.00 $12.3k | Held since 2026-08-13 |
| Fold Type Foundry | •••• 0000 4916 3320 7781 0000 | USD 195.00 $195 | Failed 2026-08-16 |
| USD subtotal · 3 of 5 records Total | USD 14,895.00 $498,015.00 | ||
- Amounts abbreviated to $2.4k in rows someone has to reconcile B1
- A EUR payout rendered with a dollar sign — the currency is simply lost B1
- JPY shown with two decimals. The yen has no minor unit; those digits are invented B1
- A total that sums three currencies into one number, and names no record count B5
- "Something went wrong" — no reason, no remedy, and no status ages anywhere B4
- Full account numbers in the DOM, and Delete is the loudest control on screen B6 · B7
The screen looks fine. The numbers are wrong.
Try the toggle aboveA coding agent has no opinion about how your product should look, so it reaches for the most common thing it has seen. That part is well known, and it produces software that is anonymous but harmless.
The part nobody talks about is that it has no opinion about money either. It will happily abbreviate a figure someone is reconciling, format a euro payout with a dollar sign, add three currencies into one total, and put a full account number in the DOM — because none of that looks like an error in a code review, and all of it renders beautifully.
These are not edge cases. Every one of the six defects above comes from code an agent will write on request, today, unprompted.
The float problem is the clearest example. Ask for a payments feature and you will get amounts stored as decimal numbers. Add a thousand one-cent charges in JavaScript and you get 10.000000000000186, not ten dollars. It passes review, it passes a casual test, and it is wrong on a balance sheet.
Daybook fixes the appearance and the arithmetic in the same install.
What it knows about money
Seven sections · the part that isn't stylingFinancial timestamps carry a timezone. Initiation and settlement are different dates and both are shown when they differ. A closed accounting period is read-only and has to look it.
ISO in columns so they sort, written out in prose so they readA state machine, not a set of labels. failed and returned stay separate — failed money never left, returned money left and came back, often with a fee. Pending is not an error.
A bare "Failed" is not an expressible state: reason and remedy are required propsEntries are immutable; a correction is a new opposing entry, never an edit. Every total ties to the rows displayed, states its record count, and says so when a filter is applied.
If your UI has an edit control on a posted transaction, that is a bugThe confirmation names the amount, the currency, and the recipient. Above a threshold it requires typed confirmation. The destructive action is never the loudest control on the page.
"Are you sure?" is not a confirmationAccount identifiers are masked at the render layer, so a full number cannot reach the DOM by accident. Nothing sensitive goes in a URL. Audit rows record who, what, when, and the before and after values.
"Updated by T. Zaid" without the values changed is not an audit trailHow the rules stay applied
The file your agent reads every timeRules in a PDF get read once and forgotten. Rules in a component library get bypassed the moment someone is in a hurry. So Daybook ships them two ways.
In the types. An amount is { minor, currency }, so a float cannot be passed. sum() throws on mixed currencies. PaymentFailure requires a reason and a remedy. Total requires a record count. The wrong thing is not expressible.
In the agent file. CLAUDE.md and AGENTS.md sit in your project root and are read on every request. You stop describing the styling and the conventions — you say "build the refunds screen, follow the payout-run pattern," and it comes back correct.
# PART B — How money behaves ## B2. Computing amounts Store and compute in integer minor units. Cents, not dollars. Never use a float for money — 0.1 + 0.2 !== 0.3 and in a financial ledger that is a defect, not a quirk. ## B4. Payment state Never render a bare failure. Failed alone is not an acceptable UI state. Every failure shows the reason and the remedy: "Failed — the linked account was closed on 9 Aug. Add a new account to retry." pending is not a warning. Most payments spend most of their life pending; styling it as an error trains people to ignore it. ## B5. Ledger integrity Every total must tie. A displayed total is the sum of the rows shown. A total that silently spans more rows than are visible is a wrong number.
What's in it
One folder · no build step| Component | Detail |
|---|---|
| Agent file | CLAUDE.md and AGENTS.md. Part A is the visual system, Part B is the seven sections above. Works with Claude Code, Codex, Cursor, and Copilot — it is plain Markdown. |
| Money components | Minor-unit Amount type, currency-aware formatting, masked account numbers, the payment state machine, amount input that never round-trips through a float, typed transfer confirmation, audit entries, closed-period locking. |
| Stylesheet | One framework-agnostic CSS file — tokens plus every component class, scoped so it cannot leak. No build step, no dependencies. React, Vue, Svelte, Rails, or plain HTML. |
| UI components | Around thirty typed React components. Tables with tabular figures and totals that tie, stats, fields, dialog on native <dialog>, status, notice. |
| Screen patterns | Seven finished screens the agent file points at by name — payout run, reconciliation, dispute, invoice, dashboard, account record with a running balance, and settings. Chosen by shape, so between them they cover most of what money software has to render. |
| Tailwind theme | A v4 @theme block that remaps the utilities onto the system, so a component pasted in from elsewhere gets pulled in rather than punching a hole. |
| Figma | A plugin that builds the design file — variables with Day and Night modes, text styles, and the component library, generated from the same tokens.json the CSS uses. A hand-built Figma file starts drifting the first time a token changes; this one is one command and one click away from matching the code again. |
| Guide | Install, self-hosting the fonts, merging into an existing CLAUDE.md, what you can safely change, and what breaks the system if you touch it. |
| Invoices and statements print correctly — chrome dropped, palette flattened to black, table headers repeating across sheets, and no row split at a page break. The printed copy is often the one that ends up in an audit file. | |
| Both themes | Light and dark drawn separately rather than inverted. Every text token clears WCAG AA at 4.5:1 against its own ground, in both. |
Pricing
One payment · no subscription · prices exclude tax- The full stylesheet
- All seven screen patterns
- Install guide
- Unlimited projects
- No agent file
- No money components
- No Figma file
- Everything in Free
- The agent file, Parts A and B
- All money components, typed and tested
- Figma file and Tailwind theme
- One developer, unlimited projects
- Ship it inside products you sell
- Everything in Solo
- Up to five seats
- Twelve months of updates
- New patterns as they ship
Questions
Is this compliance or legal advice?
No, and please do not treat it as any. Daybook is a design system. Part B encodes widely-held conventions for presenting money in a user interface — precision, currency handling, state, masking, audit trails. It is not a compliance product.
It does not make you PCI DSS, SOC 2, PSD2, or GDPR compliant, and it does not know your jurisdiction's rules. Nothing here replaces your own legal and compliance review. Where a Daybook convention conflicts with a regulator or your counsel, follow them.
Do I have to use Claude Code?
No. The instruction file ships as both CLAUDE.md and AGENTS.md, which covers Claude Code, Codex, Cursor, and Copilot. It is plain Markdown — any agent that reads project context will use it.
And none of it is required. If you write every line by hand you still get the stylesheet, the components, and the rules.
What if I don't use React or Tailwind?
Both are optional layers. The source of truth is one CSS file with plain class names, scoped so it cannot leak into the rest of your site. Vue, Svelte, Rails, Django, or static HTML all work unchanged.
The money components are the exception — those are React. The rules they encode are documented in the agent file, so porting them to another framework is a readable afternoon rather than a research project.
My product isn't payments exactly. Does it still fit?
It fits anything where a number on screen is somebody's money or obligation: invoicing, accounting, payroll, lending, subscriptions, marketplaces, treasury, expenses, and internal finance tools.
It fits less well if money is incidental to your product — a checkout page on a content site does not need a ledger's worth of rules.
Can I change how it looks?
The accent is the intended customization point — override one variable and the identity follows. The guide covers what is safe to change, what is risky, and what quietly breaks the system.
Part B does not depend on Part A. If you replace the visual layer entirely, the money rules and components still hold.
Why is my total higher than the price shown?
Prices here exclude tax. Depending on where you are, checkout adds VAT, GST or sales tax at your local rate — so a $99 licence comes to about $124 in Sweden, $119 in the UK, and $99 in most of the United States.
Paddle is the merchant of record and collects and remits that tax, which is why it appears at checkout rather than here. If you are buying as a VAT-registered business, enter your VAT number at checkout — the tax is then zero-rated or reverse-charged and you pay the listed price.
What does the licence allow?
Solo covers one developer, unlimited personal and client projects, and you may ship it inside products you sell. Team covers five seats.
What you may not do is redistribute or resell the system itself — as a template, a theme, or a component library — in whole or in part.
Take the visual half and see if it holds up.
The complete stylesheet, all seven screen patterns — payout run, reconciliation, dispute, invoice, dashboard, account record, settings — and the install guide. The agent file and the money components are the paid part. Everything else is yours, for any number of projects.
This page is built with it. That is the demo.