Closed periods stay closed
Close a period and any edit to it raises a database error at the trigger layer. Application code cannot bypass it. No backdated invoice, no quiet adjustment, no surprise restatement after the fact.
Your books shouldn't be editable after you close them.
Financial safety enforced at the database, not promised in a manual. For logistics, manufacturing, and 3PL operators who outgrew the books app but were priced out of the enterprise suite.
The spreadsheet trap
When the back office is held together by spreadsheets, integrity is a hope, not a rule.
Fragmented, manual spreadsheets do not enforce anything. A closed month can be reopened with a keystroke. An invoice number can be skipped, reused, or quietly renumbered. A figure can be backdated and nobody finds out until reconciliation, if anyone reconciles at all. Every tab is one accidental edit away from a number that no longer ties out.
- Periods that close in name only and get edited weeks later.
- Gaps and duplicates in invoice and PO numbers that auditors flag.
- An audit trail that is itself editable, so it proves nothing.
- Reconciliation that never holds, because the source data keeps moving.
Kitstak moves those rules out of the spreadsheet and out of the application, down into the database where they cannot be bypassed.
Integrity enforced at the database, not the application.
The guarantees below are constraints and triggers inside the database. Not application code that can be patched around. Not a policy in a manual that someone forgets.
Gap-free document numbering
Invoice, PO, and document numbers are sequential and gap-free even under parallel writes. Auditors and customers never ask why a number is missing, because it never is.
Tamper-evident audit log
Every change appends to a log with a per-row hash chain, verified on a schedule. The trail cannot be rewritten after the fact. Not by a user, not by an admin, not by us.
Journal entries that write themselves
Send an invoice, post a payment, approve a vendor bill. The matching journal entry writes itself at the database trigger layer. The books balance as you operate, without a bookkeeper holding it together.
Money in cents, end to end
Integer cents end to end, half-even rounding everywhere, tax rate snapshotted at issuance. No floating-point drift ever touches a dollar of your financials.
No duplicate writes, ever
Every state-changing action is idempotent for 24 hours. A double-click or a network blip cannot create a second invoice or a phantom payment.
Who this is for
Built for operators drowning in spreadsheets.
Logistics and 3PL operators
Receiving, inventory, and customer billing scattered across a dozen tabs. Move it onto one chassis where every stock movement and every invoice is enforced, audited, and reconciled by the database.
See the 3PL moduleManufacturers
BOMs, production runs, and finished-goods costs tracked in spreadsheets that never quite reconcile. Get a build floor your accountant can actually audit, costed at the moment of consumption.
See the Manufacturing moduleOutgrowing the books app
Past what a books app plus spreadsheets can hold, but priced out of a six-figure enterprise suite. This is the middle path: enforced integrity, one chassis, live in days.
Read the ERP alternativeQuestions
What "enforced" really means.
What does “enforced at the database” actually mean?
It means the rule is a constraint or trigger inside the database, not a check in the application code. Application bugs, rogue scripts, and admin overrides cannot get around it. When you close a period, the database itself rejects any write to it.
Can an admin edit a closed period or the audit log?
No. Closed-period writes raise a database error regardless of user role, and the audit log is append-only with a per-row hash chain, verified on a schedule. There is no “edit history” button, by design.
We run on spreadsheets today. How hard is the move?
Most operators are running on the chassis in days, not months. Customer zero, a real Bentonville 3PL, replaced its spreadsheet stack in five business days. Ask the founder for a walk-through.
How is this different from the books app we already use?
A books app handles the general ledger well, but its audit log is editable and it has no operational backbone. Kitstak runs CRM, operations, and accounting in one chassis, with integrity enforced below the application layer. The comparison page lays out both sides.
Do we need to be technical to benefit from this?
No. The integrity is invisible until it matters. You operate normally; the database quietly refuses to let the books drift, gap, or get rewritten.
Still weighing it against the books app? See the honest side-by-side comparison.
Stop hoping the numbers tie out.
If your books can still be edited after you close them, that is a risk you can retire this quarter. Talk to the operator who built the chassis to prevent it.