When payroll, bookkeeping, sales and delivery all feed one ledger, the risk isn’t a hard calculation. It’s the same thing being recorded twice, or half of something being recorded when a step fails.
Record the intent and the entry together
When a payment, a bank categorization or a payroll run reaches the ledger, two things are written in a single database transaction: a record of what was asked for, and the journal itself. Either both happen, or neither does. A failure can’t leave a journal with no explanation, or a request that claims to be done but isn’t.
The same request can’t post twice
Each request carries a key that identifies what it’s for. If a step is retried, or two parts of the system ask for the same thing, the code looks up that key and finds the document that already exists. This is what the record of intent is really for, more than anything else.
Not everything should post by itself
An invoice raised by Booking or Forms isn’t posted automatically. It waits until someone in your organization posts it. That’s a deliberate choice: those apps can prepare the work, but a person decides when it counts in your books.
Some invoices can post by themselves. A sales order posts its invoice only when whoever raises it asks for that, and recurring plans only when you turn that on in Finance. Dispatch posts a job’s invoice as soon as every line has an account, and leaves it as a draft until then.
History is added to, not rewritten
- Each finalized pay run posts one balanced journal.
- Posting into a closed period is refused.
- In Bookkeeping, a mistake is corrected by reversing the posted item with a reason, so the original and the reason both stay.
Where this has limits
- This isn’t a general background queue. Recurring billing retries its own failed runs, but elsewhere a failed step is reported then and there, and someone runs it again.
- Manual journals are posted directly, with no record of intent.
- Sending tax returns stays with you. Have your accountant review results before you rely on them.