Finance operations

Beyond the daily document work, Accounts carries the periodic machinery a finance team runs on a calendar rather than on demand: planning against a budget, depreciating an asset register, restating foreign-currency exposures at a closing rate, releasing deferred revenue, and generating the documents that repeat. Each of these is a screen with its own run action, and each posts to the general ledger through the same seam every other document flow uses.

They live in two groups in the left-hand navigation. Finance Ops holds Budgets, FX Revaluation and Revenue Recognition; Operations holds Fixed Assets, Recurring and Dunning. Each is behind its own permission, so a company can open the asset register to one team and the revaluation runs to another.

Budgets

A budget is a plan for a fiscal year, expressed one GL account at a time. You give it a name, a fiscal-year start and end and a period granularity — monthly, quarterly, half-yearly or yearly — and Accounts derives the period grid from those three: the first period starts on the fiscal-year start, each later one steps forward by the granularity’s months (day-clamped for short months), and the grid stops at the fiscal-year end.

The budget’s own page is that grid. Add a GL account and it becomes a row; each period is a column; you type planned amounts into the cells and press Save lines. Row totals, column totals and a grand total update as you type. Saving replaces the whole grid in one go — up to a thousand cells — so removing a row and saving is how a line is deleted. Amounts are planned figures, not postings: nothing about a budget reaches the ledger.

A budget is DRAFT while you build it, ACTIVE once you commit it, and ARCHIVED when it has served its year. Only a draft can have its header or its grid edited, so Back to draft is the way to reopen an active budget for a change; archiving keeps it for reporting, and an active budget cannot be deleted until it is archived first. Budget names are unique within a company. If you shorten the fiscal year or change the granularity while the budget is in draft, any line that no longer sits on the grid is dropped the next time you save.

Budget vs actual on the budget’s page opens the report that lays your planned figures beside real journal movement for the same accounts and periods. The report works from the grid whatever state the budget is in — activating a budget locks the plan, it does not switch the report on.

Budget lines are held at one grain — a GL account and a period. Accounting dimensions do not yet split a budget line, so a budget is planned at the account level even where the ledger records the cost centre or department behind the actual.

Fixed assets

The asset register tracks what you own, what it has depreciated, and what it was worth when you disposed of it.

Asset types

Types come first, under Settings → Asset Types (one of the master lists). A type is a depreciation profile shared by a class of assets: a default method, a default life in months or a default annual rate, and the three GL accounts an asset of that class posts through — the asset account it is capitalised in, the depreciation expense account, and the accumulated depreciation contra account. A type cannot be deleted while live assets reference it.

Registering an asset

New assets take a number (auto-numbered as FA-… when you leave it blank), a name, an optional type, purchase and in-service dates, a purchase cost and a salvage value, and the schedule parameters: method, life or rate, a monthly or yearly frequency, and whether the first period is charged pro-rata or in full. Each asset can also override any of the three GL accounts.

Two rules about where those settings come from are worth knowing. Schedule defaults are copied from the type onto the asset when it is created, so editing a type later never rewrites the schedule of an asset already on the register. GL accounts are not copied — they resolve at posting time as the asset’s override, or the type’s account when there is no override.

Registering an asset is bookkeeping about the asset, not a posting: neither creating nor activating one writes a journal in the web app, because the cost is normally already on the books from the bill that bought it. (The API can post an optional capitalisation entry as part of activation; the web app does not use it.)

Activate is what makes an asset eligible for depreciation, and it validates the schedule before it will: an in-service date and a positive cost are required, straight-line needs a life, the declining methods need a rate, and the GL accounts must resolve — the asset account always, the depreciation and accumulated accounts unless the method is None. A failure comes back as a toast naming what is missing rather than a half-activated asset. Editing and deleting are draft-only.

The depreciation run

Run depreciation on the register asks for an as-of date and posts every period that has fallen due up to it, for every active, in-service asset whose method is not None. This run executes — it is not a stub. Per period it posts one journal debiting the depreciation expense account and crediting accumulated depreciation, dated the last day of the covering month, records a history row against the asset, and raises the asset’s accumulated total. An asset whose accumulated depreciation reaches cost minus salvage flips to FULLY_DEPRECIATED. The asset’s page then lists every posted period with a link straight to its journal.

The arithmetic is fixed and documented. Straight-line charges (cost − salvage) ÷ life months per month, twelve of those for a yearly schedule. The declining methods — written-down value, and the 200% and 150% variants — apply the asset’s rate as an annual percentage of the current net book value, so the charge falls each period. Pro-rata scales the first period only, by the share of that month the asset was in service. Every charge is clamped to what is left of the depreciable base, which is why straight-line absorbs its rounding in a final stub period and the declining methods stop cleanly at salvage rather than running to zero.

The run is idempotent — each asset and depreciation date can only be posted once, so re-running the same date reports nothing due and posts nothing. It is also a single transaction across the whole company: if any one journal is refused, most plausibly by a closed fiscal period, the whole run rolls back and nothing is posted. Nothing schedules it for you; it runs when someone presses the button, or when an external scheduler calls the same endpoint on a monthly timetable.

Disposal

An active or fully depreciated asset can be disposed of from its own page, either sold with proceeds or written off with none. One journal posts on the disposal date: accumulated depreciation is debited away, the proceeds are debited to cash, the asset account is credited for its cost, and the difference — proceeds plus accumulated, less cost — lands as a gain or a loss.

Two things to know before you use it. Run depreciation first. The web disposal does not charge the final part-period, so the gain or loss is measured against the net book value as it stands, and any uncharged periods are simply never charged. And the proceeds and the gain or loss are posted to your control accounts — the first bank or cash control account, and the revenue or expense control — rather than to accounts you nominate on the dialog.

FX revaluation

Invoices and bills raised in a foreign currency sit on the books at the rate they were booked at. When that rate has moved and the document is still open, the balance sheet is carrying a number the market no longer agrees with. A revaluation run restates those open balances at a closing rate and posts the unrealised difference.

Start one from FX Revaluation → New revaluation run, with an adjustment date, a three-letter currency code and the rate to restate at. That rate is the one you type — the run does not read the stored exchange rates and does not fetch a feed, so it is your closing rate, deliberately.

The run then locks and snapshots every open exposure in that currency: invoices that are sent, viewed, partially paid or overdue with a balance still owing, and bills that are open, partially paid or overdue. Each balance is valued twice — at the rate its own document was booked at, and at your run rate — and the results are aggregated per contact into the exposure table you see on the run. Receivables restated upward are a gain; payables restated upward are a loss, and the run’s total is the net effect of both. One balanced journal posts the whole restatement, moving the AR and AP control accounts against the revenue and expense controls. There is no separate FX gain/loss account to nominate.

If no exposure moved — no open documents in that currency, or every one of them already booked at your run rate — the run is kept as a DRAFT record with a zero total and no journal, and the app tells you there was nothing to restate.

Bank balances are not revalued. The bank book records amounts in your base currency, so a foreign-currency bank account has no separate balance to restate, and the run leaves it alone.

Revenue recognition

Revenue you have invoiced is not always revenue you have earned. A twelve-month subscription billed up front is a liability on the day it is raised and becomes revenue a month at a time. Revenue recognition is the pair of tools that expresses that: rules that describe how a line’s revenue is released, and schedules that hold the periods themselves.

Rules

A rule, authored on the Rules tab, carries a name, a method, and two GL accounts: the deferral account — the liability revenue waits in — and the recognition account it is released into. Two methods have engines behind them today. IMMEDIATE produces a single period on the invoice date. STRAIGHT_LINE splits the amount into equal monthly parts over a duration you set, between one and 120 months, with the rounding remainder absorbed by the last period so the schedule always sums to the line exactly. Rules can be deactivated, edited, and deleted — though not while planned schedule rows still reference them.

For the ledger to tell the story end to end, the invoice line itself should credit the deferral account when the invoice is issued, so that the run has a liability to release. Set that per line in the line editor, or set it once as the item’s sales account.

Generating schedules

A rule reaches an invoice line in one of two ways: the item on the line carries the rule — set on Items → the item → Revenue recognition — or you nominate a fallback rule when generating. Generate schedules asks for an issued invoice and, optionally, that fallback; drafts, cancelled and void invoices are refused, because recognition applies to documents that have actually been issued. Each line then resolves its rule (its item’s rule first, the fallback second), and a line that resolves neither is skipped rather than guessed at. When a run schedules nothing at all it tells you why — how many lines were already scheduled, how many had no rule, how many had nothing to recognise.

What gets scheduled is the line’s net revenue — the line amount less its tax, because tax is a liability and never revenue. Generation is idempotent per line: a line that already carries schedule rows is left alone, so running it twice cannot double a schedule.

The Schedules tab lists every row — invoice and line, period, planned and recognised amounts, the rule and the journal once posted — filterable by status.

The posting run

Recognize due asks for an as-of date and posts every planned row whose period has arrived. This run executes: it aggregates the due rows per deferral-and-recognition account pair, posts one journal for the whole run debiting each deferral account and crediting its recognition account, flips the rows to RECOGNIZED and links them to that journal. Rows that are already recognised have left the scan, so re-running the same date changes nothing.

Recurring and dunning

Two more generators sit under Operations, and both are documented in full with the documents they produce.

Recurring holds invoice templates and generic bill, expense and journal-entry templates on one screen, a tab each, with a Run now that generates every occurrence that has come due and advances the schedule — see recurring invoices.

Dunning holds the escalation policies and the collections runs that chase overdue receivables, and its run doubles as the sweep that marks invoices overdue in the first place — see dunning and collections.

Nothing here runs itself

Accounts ships no internal scheduler. The depreciation sweep, the recognition run, the recurring generators and the dunning run all happen when someone presses the button in the app, or when an external scheduler calls the same authenticated endpoint on a timetable you choose — typically monthly for depreciation and recognition, daily for dunning. Each of them is idempotent, so a scheduler that fires twice, or a run repeated by hand, does no damage.

Connects to

General ledger — every posting run here writes a balanced journal through the shared seam, and a closed fiscal period will refuse one.
Receivables & payables — the invoices and bills that FX revaluation restates and revenue recognition defers, plus the recurring and dunning engines in full.
Reports — budget vs actual reads the budget grid against real movement.
Audit trail — the mutating actions on these screens are recorded like any other.