Accounting thatdoesn’t invent money.

How much can we spend today and still have the rent next week? Sounds simple. In practice some of the money is already promised, some arrives only after a game, and some, who knows when.

Before this there was a spreadsheet with a tab per employee and questions like “why is my balance this?”. We built the first version in June on top of the payroll data: income from the booking calendar, pay, regular bills. In September the finance core was rewritten with explicit accounting rules.

The most dangerous spreadsheet is the one that confidently shows the wrong number. So the core’s main rule is simple: if an account balance is unknown, a rate is missing or the last reconciliation is over 14 days old, no money total is calculated. A “—” and a question to close appear instead.

The rule fired on day one. On 6 October, when the “how much can be distributed” calculation went live, the tool showed “—” instead of an amount: confirmations from the head of the business were missing. Uncomfortable, but right. The rules were then refined: small unidentified amounts became a warning rather than a block.

A booking balance comes in. In the old setup it could be counted twice: as income and as a change in the account balance. Now it is one operation that records the payment and updates the chosen account. Recurring bills such as rent are spread across their dates, and a part-payment or postponement affects only its own date.

Future money lives in scenarios kept apart from facts: no future income, existing bookings only, base and strong. Distribution is shown in three variants. “Safe” relies only on the current balance: the historical check showed that even a cautious estimate of future balances misses more often than the acceptable 5%.

The forecast started with a full CRM export: 3,440 deals since December 2023. Two things that used to be hunches were confirmed. After 20:30 Omsk time, almost nobody books for the same day: of 428 successful same-day bookings, 3 were made after 20:30. And cancellations of dated bookings run at 7.2%, not the 22% the old model assumed.

A separate model estimates how much of the expected balances on existing bookings the company will actually receive. On the historical check it cut the average error by 17% three days ahead, 26% a week ahead and 24% two weeks ahead.

The sales forecast is honestly labelled “limited validation”, and its error is shown rather than hidden.

Staff are paid piece rates: host, entertainer, actor, different packages and extras. Pay used to be worked out in a spreadsheet from memory and chat messages. Now it is calculated from events: every accrual becomes a line that can be checked. A total without a breakdown isn’t allowed.

Penalties go into a separate append-only log: cancelling a penalty adds a new entry rather than deleting the old one. Lateness is calculated by the server from the rule. Every employee has a personal page with accruals, the amount due and penalties.

Self-employed staff must send a tax receipt for every payout. For years the receipts sat in private messages and work chats. Now the system collects them from Telegram, reads the QR code and checks each receipt with the tax service. A cancelled or unknown receipt is rejected, and a repeat isn’t counted twice. How many receipts are missing shows on the employee’s page.

Payouts don’t get lost in chats either. An AI assistant finds messages in work chats such as “gave 3,000 from the Bratskaya till” and offers a card: “Yes, record it”, “No” or “Another employee”. A person confirms every entry, and the payout log gets it without retyping.

The payout log is protected against loss. A write that would leave the log with fewer rows is blocked. The previous version is saved before every write, and a daily copy is kept for 60 days.

When the old server became unreachable on 8 October, the payout log and finance state were rebuilt from several sources and moved to the new server. 225 chat messages that looked like payouts didn’t go into the log automatically: a person checks them.