SAYBOOKS

The books you can talk to.
The books that stay books.

Saybooks is an ERP where your agent and your interface are the same system — one command registry, one rulebook, one audit trail. Tell Claude to ship the order, or click the button. Same command, same rules, same record of who did what and why.

Try the live demo Watch a rule refuse an agent No signup. You get a private sandbox with example books; it resets daily.

two ways in

Saybooks is for people who run books, and people who build systems.

For operators — run your business on it

An order-to-cash system a 5–200 person company can actually live in.

Quotes, orders, a credit gate that counts committed value, partial shipments and backorders, invoicing from what shipped, returns and credit notes, cash application, write-offs, statements, and an aging your controller would open. Plus the part nobody else has: you can hand routine work to Claude and every act it takes is logged, governed by the same rules, and refused in plain sentences when it shouldn't happen.

  • Try the demo — your own private books, seeded with a realistic morning, including one order that deliberately trips the credit gate.
  • Connect your Claude — one command from the demo sidebar, then just talk: “receive 20 Widget B and finish Northwind's order.”
  • Watch the trail — your words become attributed, reasoned ledger entries next to the human ones.
Open the demo 2-minute quickstart Not for your real books yet — the demo resets daily, and we'd rather say so here.
For builders — write a module for it

A spec that bites back, and a registry that generates both surfaces.

Every business act is declared once; the MCP tool, the UI form, the guard evaluation and the audit row are all derived — a contract test fails the build if they drift. The order-to-cash area is governed by a written spec: 21 invariants, 25 acts, 9 executable conformance scenarios. Modules own their tables, carry their doctrine, and are held to an 11-gate contributor contract. The endgame is competing implementations of the same area, certified by replaying the same scenarios.

  • Read the spec live — the demo's Spec tab shows acts, invariants, and the evidence for each, derived from the last conformance run, never asserted.
  • Walk the scenarios — every rule taught as filled-in forms, one step at a time, refusals included, executing for real as you click.
  • Talk to us about a module — the code is private while the spec stabilizes; the spec and its scenarios are public in the demo.

one log, two kinds of hands

This is a real audit trail from a real session.

The purple rows are Claude, connected over MCP. The blue rows are a person, clicking. They are not two systems reconciled — they are one system, and the log can tell you, for any number in the books, who put it there and the reason they gave.

Refusals are logged too — a blocked agent action is exactly the thing you want to be able to review later.

claudeconfirm_order✗ refused — Credit check failed for Contoso Ltd… Short by $1500.00
claudeinvoice_shippedINV-0002, $400.00 — billed what shipped, never what was ordered
claudeship_orderthe open 5 × Widget B — carrier left blank rather than invented
claudereceive_stock“Supplier delivery received; no PO reference supplied”
samrecord_payment“bank feed — no remittance advice yet”
claudeapply_payment“remittance confirmed by their AP clerk on the phone”
saminvoice_shipped“billing what shipped, never what was ordered”

rules that refuse, in sentences

When the agent asked to confirm an order past its credit limit, this happened:

Credit check failed for Contoso Ltd. Order $2500.00; available $1000.00 (limit $1000.00 less open AR $0.00 and committed $0.00). Short by $1500.00.

That sentence is written once, in the rule itself. The greyed-out button shows it as a tooltip. The agent receives it verbatim and relays it. The test suite fails if they ever differ. And the rule's own documentation tells the agent what not to do next: don't split the order, don't invoice early, don't quietly raise the limit — report the shortfall and let a person decide. In our sessions, that is what it does.

why it can't drift

Every capability is declared once. Everything else is derived.

Two surfaces, one declaration

Each business act — confirm an order, apply a payment, write off a balance — is defined one time. The agent's tool, the form in the UI, and its validation are all generated from that single definition.

Enforced: a contract test asserts field-for-field parity. Hand-write a form and the build fails.

A spec you can replay

The order-to-cash area is governed by a written spec: 21 invariants, every act, every lifecycle. Nine executable scenarios prove the implementation follows it — including the refusals.

See it: the demo's Spec tab walks every scenario as filled-in forms, one step at a time, running live.

Nothing writes off the record

There is exactly one door to the books. A click and a tool call go through the same command, the same guards, the same transaction — and land in the same log, with an actor.

Including no: a refused command is recorded with who asked and why it was refused.

a governed agent, end to end

The Contoso order, as it actually played out

  1. The gate refused the agent. Order $2,500 against a $1,000 limit — refusal logged, with the arithmetic.
  2. The agent stopped and laid out options. Raise the limit, split, prepay, or decline — noting it had raised nothing and split nothing, and that Contoso had no payment history to justify more credit.
  3. A person decided. The limit moved to $3,000 as its own logged act, with the approver's reason on the record, verbatim.
  4. The same order confirmed. The earlier refusal stays in the log beside the approval — the trail you'd want when someone asks why the limit moved.
  5. Asked to do something the books contradicted, it declined. Told to apply “the rest” of a payment that was already fully applied, it checked the log, found $0.00 unapplied, cited the evidence, and made no write. The books beat the prompt.

try it in two minutes

Your sandbox is already waiting.

1

Open the demo. You get a private set of books, seeded with a small distributor's morning: a part-shipped order, an open invoice, cash without a remittance, and one draft order left there deliberately — confirming it trips the credit gate. Try it.

2

Point your own Claude at the same books. The sidebar shows your command — claude mcp add -t http saybooks https://saybooks.io/mcp/<your-sandbox> — or add the URL as a custom connector on claude.ai. Then just talk: “receive 20 Widget B and finish Northwind's order.”

3

Keep the Audit trail tab open while you do. Watching your own words become attributed, reasoned entries in a ledger — next to the human ones — is the product.

plainly

What Saybooks is, and isn't, today

IS

  • A working order-to-cash vertical: quotes, orders, a real credit gate, partial fulfilment and backorders, invoicing from fulfilment, returns and credit notes, cash application, write-offs, statements, aging.
  • Spec-governed: 21 invariants, 25 acts, 9 replayable conformance scenarios.
  • Calibrated for a 5–200 person company selling goods or services on account.
  • This demo — free to play with, wired for both hands.

ISN'T — yet, or on purpose

  • Not multi-currency, multi-entity, or a tax engine — tax is captured and frozen per line; computing rates is an integration's job.
  • It never emails a customer, charges a card, or books a shipment. It records what happened. Outbound is other software's work.
  • Not a place for your real books today — the demo resets daily, and we'd rather tell you that here than let you find out.