An ERP with AI invoice capture and an audit trail that holds

The desktop files turned out to be SQLite databases whose records were protobuf blobs. We wrote a decoder for them and recovered inventory, customers, suppliers and the full purchase and sales invoice history with line items, quantities and rates, rebuilding customer names from the audit trail where the live records had been blanked, and merging entities across books that used different identifiers. The date epoch was calibrated against a known paper invoice and verified: one document decoded to the correct date with all seven line items matching the printed amounts exactly. Loads were made idempotent, so re-running corrects rather than duplicates.

Photograph a supplier invoice and a vision model reads the line items. Nothing is written on that basis alone: the extraction is presented for review, and only the person's confirmation creates the purchase invoice and moves stock quantities, item cost prices and the supplier balance. The scanner runs across multiple API keys per provider, rotating on a schedule and advancing automatically on rate limit, quota or auth failure before falling through to a second provider. With no keys configured it says so plainly instead of failing silently.

Invoices move draft → pending review → approved → unpaid → partial → paid, and the approval step is not decorative: drafts and invoices still under review are deliberately excluded from revenue, purchases and outstanding totals on both the lists and the dashboard, because nothing is owed until an invoice is approved.

Every write goes through a single data-access layer that stamps the acting user and appends a field-level diff to an append-only table. That table grants staff select and insert only (there is no update or delete policy), so the trail cannot be rewritten through the API even by the application itself. Deleting sets a timestamp rather than destroying the row; only an administrator can purge, and the audit entry outlives the record.

Roles are a grid of eighteen modules against five actions, editable per role and overridable per person. Navigation hides what you cannot view, routes redirect, the write layer checks before touching the database, and a trigger discards any change a non-administrator makes to their own role or permissions. The layers above the database are the application being tidy; the trigger is what actually stops privilege escalation.