Rules you should understand

A handful of rules shape how the ledger behaves. They're not optional settings — understanding them will save you from wondering why an edit didn't "take", or why two reports that both look at the same month don't quite agree.

Posted entries are immutable

Once an entry is posted, its two sides are locked — permanently. There is no "edit a posted entry" anywhere in the module, by design: a ledger you can quietly rewrite after the fact isn't a ledger anyone can trust.

To correct a posted entry, reverse it — a new entry posts with the legs swapped, the original stays exactly as it was with a link to its reversal — and then book a new entry with the right figures. This is also what happens automatically when the record behind an automatic posting changes: for example, editing a booking after its revenue has already posted doesn't rewrite the old entry, it reverses it and posts a fresh one.

Only a draft can be edited directly, or deleted outright — that's the point of saving something as a draft rather than posting it immediately.

Locked months

An administrator can lock a month once it's finished — see EÜR, GuV and VAT and the Profit/Loss report's own locking a month for the parallel concept on the statistics side. Locking is per company, across every asset, and months lock in order — you can only lock the month right after the latest locked one.

If something tries to post into an already-locked month — a manual entry you back-date, or an automatic posting from a document that was itself edited late — Gurita doesn't reject it outright. Instead:

• A manual attempt to book directly into a locked month is rejected, with a message telling you to pick a date in the open period instead.
• An automatic posting is silently redirected to the first still-open month, carrying a note recording the date it actually belongs to. You'll see this as the small clock icon on the entry's reference in the Journal, and as a "Posted late — belongs to {date}" note on its entry details.

Only the most recently locked month can be unlocked, and both locking and unlocking require Administrator access.

Unsaved changes

Every dialog in this module — booking an entry, editing an account, a posting rule, a supplier invoice, a payroll run, a recurring template — asks "Discard changes?" if you try to close it with something typed in that you haven't saved. Choose Discard to lose the changes, or Keep editing to go back to the form.

Suspense

1900 Suspense is where a posting lands when nothing — no posting rule, no source default — could resolve which account it belongs on. It's never a failure: the entry still posts, in full, exactly as it would anywhere else; it's simply parked and queued on the Mapping tab's suspense list for someone to assign a real account.

Common reasons something lands here: a payment method with no account claiming it and no company-wide default for it; a bank line from an account shared by more than one property, where Gurita can't tell which one it belongs to without you picking; or money collected on behalf of another asset in your company.

The 1900 account's own balance always equals the net of whatever is currently sitting in the suspense queue — so a Chart of Accounts row you don't expect to see money on is your other early signal that something needs assigning.

Items with several taxes

An item can be charged more than one tax at the same time — a service tax inside the price plus a VAT added on top is the common case. Gurita books one VAT line per tax: the entry's split shows 3300 Output VAT twice, once for each tax and each labelled with its name and rate, and the VAT tab lists the sale in both bands.

Two things follow from that:

• The entry's single VAT % figure, shown in the journal and on the entry dialog, is a summary of the whole entry, not one of the taxes. Where the taxes are charged differently (one inside the price, one on top) it is an effective rate and will not match either tax. The per-tax lines, not that figure, are what the VAT return is built from.
• In the VAT tab, each band's base is the item's whole net turnover, because each tax was levied on all of it. Bases are therefore not additive across bands; only the VAT column is.

The entry's Net, VAT and Gross totals are exactly what they were before the split, so nothing on the EÜR, the GuV, the KPI cards or the Profit/Loss reconciliation changes.

How the ledger compares to the Profit/Loss report

Turning Bookkeeping on doesn't replace the Finance report's Profit/Loss tab — they stay two separate views, on purpose, and a reconciliation strip on the Profit/Loss tab shows you how they compare for the same period. See Ledger reconciliation in the Finance report chapter.

The two numbers can legitimately differ, and the strip tells you why for each category:

• Drafts — a draft entry counts toward the ledger's "needs attention" figure but not toward EÜR, and the Profit/Loss report has no concept of a draft at all — it reflects the booking record directly.
• Suspense — money parked on 1900 hasn't reached its real account yet, so it can throw off a category-by-category comparison even though the total is unaffected.
• Manual entries — anything you've booked by hand has no equivalent booking record for the Profit/Loss report to count.
• Date/period differences — the ledger books to the entry's own booking date; the Profit/Loss report uses its own date basis (Check-In by default), so a figure can shift between months on the two reports even when nothing is actually wrong.

Backfill

Turning the module on for an existing property doesn't leave your history out of the ledger. An administrator runs a one-time backfill that enumerates every source document back to your configured start date and posts it, exactly as if the module had always been on. It's idempotent — running it a second time changes nothing, since it recognises documents it's already posted — so there's no risk in re-running it if you're unsure whether it completed. Opening balances per account, per asset, are computed as of the start date, so the ledger starts in balance rather than assuming every account began at zero.

A re-run also repairs labels without touching money. When an entry's amounts and legs still match its document but its tax name is missing or out of date — an entry posted before the per-tax breakdown existed, or a tax that was renamed in the POS settings since — the backfill attaches the current name to the entry in place. Nothing is reversed or re-posted, the entry keeps its reference, and the run reports these separately as relabelled. The next run reports zero of them.

The same pass reaches reversed entries and their stornos. An entry that was corrected before the per-tax breakdown existed still shows the old blended rate on both halves of the pair, and neither half is live any more, so no document would ever re-post it. When the entry that replaced it books exactly the same amount and VAT, the pair takes the replacement's taxes — the list, the VAT return and the details dialog then name every tax on the storno too. The run reports these as Reversed pairs; a replacement that also changed the amount is skipped, because its taxes are not the old pair's.

A backfill survives a restart. It records a checkpoint after every batch, and if the server stops in the middle of a run — a deployment, say — the run picks up from that checkpoint automatically when the server comes back, without repeating what it had already posted.

Related chapters

• Booking an entry — reversal, drafts, and the unsaved-changes prompt in practice.
• Mapping — the suspense queue itself.
• Reports — the Profit/Loss tab the reconciliation strip compares against.