Nebo · tutorial 09 · run the money

Start month-end from clean books

Every transaction categorised daily, payouts matched to orders, and a short list of what genuinely needs a human judgement call.

TimeAbout 90 minutes
Rolesbookkeeper, accounts-payable-specialist
Triggerschedule
Read this before you start

This is the first recipe that touches money, and the rules are different. Do not connect a live ledger until you have run a full cycle against a copy or a sandbox company. Nothing in this tutorial should be your first test of an employee.

Month-end is painful because a month of small decisions gets made in one sitting, badly, under time pressure. Categorising daily turns the close from an excavation into a review.

Steps

1

Give it your chart of accounts and your habits

Categorisation is judgment, and your judgment is idiosyncratic. Give it the chart of accounts plus the rules you actually apply, including the ones your accountant would raise an eyebrow at.

Software subscriptions under £50/month go to Software, not Professional Services, even when invoiced as a service. Anything from a hardware supplier over £500 is Capital, not Office Costs. Travel is split: client-attributable travel to Cost of Sales, everything else to Admin.
2

Require confidence, and a stop

The valuable output is not the categorisation, it is the honest uncertainty. Force it to separate the two.

Categorise every uncategorised transaction. For each, give your confidence. Anything you are not confident about goes on an exceptions list with your best guess and why you are unsure — do not categorise it. Never invent a vendor or a category that is not in the chart of accounts.
3

Match payouts deterministically

Reconciling a processor payout against its orders is arithmetic, and arithmetic does not belong in a model. Pull and match with a command node; let the model explain what did not tie out.

The specific danger here

A model asked to produce a reconciliation table will occasionally emit a row that reconciles perfectly and does not exist. In every other recipe that is an annoyance. In your ledger it is a number your accountant will rely on. Keep every figure on a deterministic path and let the model write only the prose around it.

4

Run daily so the close is never a cliff

"trigger": { "type": "schedule", "cron": "0 6 * * 2-6" }
5

Set the gate

Stays human

Posting a payment, writing anything off, and every revenue-recognition judgement. These are marked critical, so no global setting can loosen them and you must enable each one deliberately on this specific employee. Leave them at approval permanently, and set anything you never want attempted to blocked.

Categorising is safe to run unattended once you trust it, because it is reversible and visible. Posting money is neither.

Verify

  • Run a full month against a copy of your books and have your accountant review the output
  • Reconcile one payout entirely by hand and compare
  • Confirm the exceptions list contains the things you would have queried
  • Confirm no payment was posted and nothing was written off
  • Deliberately feed an ambiguous transaction and confirm it lands in exceptions rather than being guessed

When it goes wrong

The exceptions list is empty

The most alarming outcome, not the best one. Real books always produce ambiguity. An empty exceptions list means it is guessing confidently. Re-read the confidence instruction and check it is actually being applied.

A reconciliation does not tie out and it cannot say why

Usually a timing difference between processor payout date and order date, or fees netted before payout. Tell it explicitly how your processor settles.

Categorisation drifts over months

Rules are living in messages rather than the persona, so each run starts fresh. Move every recurring correction into the persona.