Hospitality group, Malta
Labour-cost reporting
A finance team closing six sets of monthly labour numbers by hand, from a workbook nobody could safely change.
- Multi-entity
- Payroll
- Reporting
Runs on invented data and asks for a password. Ask us and we'll open it up.
What they had
Two payroll exports landed each month and were compiled, by hand, into a twenty-nine-sheet workbook. It worked, in the sense that numbers came out of it. But the exports changed shape month to month. A column moved, a brand was added, and every change meant re-anchoring formulas by hand.
- Hard-coded ranges that silently excluded new rows
- Broken links that underreported whole lines, with nothing to catch them
- A close that depended on one person knowing where the bodies were buried
How we approached it
We did not start from a spec. We took the real exports for a real month and matched the existing workbook line for line, including the lines that were wrong, so we could show exactly which differences were bugs being fixed rather than bugs being introduced. Only once the numbers agreed did we start replacing anything.
What we built
A deterministic compile engine that resolves fields by name rather than position, so a moved column is a non-event. It produces a ledger-ready journal and an XLSX in the shape the team already knows, and every month-on-month variance comes with a plain-English explanation of what moved and why.
- Multi-entity from the start, with row-level security per entity
- Every close snapshotted, so a locked month can always be reproduced
- Flags raised on variances and missing rates before the month is locked
Where it runs
On the client's own infrastructure, with nightly database and document backups mirrored off-site. They hold the repository and the deployment. The demo here is a separate copy on invented data, with three entities rather than their eleven and not one real figure.