Inventory, sales and daily close for restaurants and shops

The short version

A system that knows what you have at every location, deducts ingredients per recipe and hands your accountant a clean file. Today it’s a working demo, ready for a pilot. No client is running it in production yet, and I say that up front.

Context

I first built the inventory system for my own store, Empire Essence, so we wouldn’t pay for an outside CRM. It worked for one business, with perfume-specific fields. When I started talking to restaurant and shop owners, I kept hearing the same pain. That’s where Restocore came from: a separate product, designed from day one for multiple locations and more than one kind of business.

Two prospects shaped it:

• A restaurant group with several locations. Their current software wasn’t delivering, and they were looking at options before their contract ran out.
• A helmet-parts shop. Counter sales, with inventory and the end-of-day close kept by hand.

The problem

Different businesses, same complaints:

• Nobody knows what’s at each location without going to count.
• The daily close lives in a notebook or a spreadsheet nobody can audit later.
• The accountant gets the numbers late and messy.
• At the restaurant, every dish sold should deduct its ingredients. Nobody does it, so losses stay invisible.

What the restaurant asked for, in their words: stability, solid inventory, purchasing, a customer base for deliveries and a screen that’s easy to use.

The approach

Before writing code, I decided what not to build. A POS with tax-compliant e-invoicing shouldn’t be built from scratch: it’s regulated, expensive to maintain, and certified providers already exist. Restocore sits next to the POS, not in place of it. It imports POS sales from a file and handles what the POS doesn’t do well: inventory, recipes, purchasing, closing and clean data.

Second decision: one codebase for two kinds of business. Each install picks a mode. Restaurant mode uses recipes, deliveries and suggested reorders. Retail mode uses SKU variants and counter sales. Every improvement helps both.

Third decision: AI only where it saves real work, with a person at the end. Invoice reading is the example.

What I built

• Inventory per location with a stock ledger: every movement records who made it.
• Counter or recipe-based sales that deduct ingredients automatically.
• Purchasing, average cost and suggested reorders.
• A saved end-of-day close per location and per day.
• POS sales import from a file.
• Role-based access for admin, cashier and warehouse. Cashiers can’t see costs or delete records. Each user only sees their assigned locations.
• Daily backups with a restore that’s verified by automated tests.
• Excel export, so owners can pull their data without asking me.
• An accounting voucher for the accountant, in beta. The final format gets confirmed with each client’s accountant.
• An agent that reads supplier invoices (photo or PDF), checks tax ID, totals, VAT and quantities, and drafts the purchase. A person reviews it side by side and confirms. Nothing is saved without that confirmation.
• An installer for the client’s own computer or server, with backups and a way to roll back an update.

Daily close, exports and backups

Z close. One close per location per day: totals by payment method (five methods), sales, discounts, cash base, counted cash, the difference and who closed. Once saved, later sales for that day are blocked, and a sale and a close cannot overlap. Previous closes stay available for review.

Siigo voucher (beta). For the accountant: a daily accounting voucher per location and date range, with debits by payment method and credits to income and VAT, controlled against the saved Z close. Up to 500 rows per Excel without splitting a day, and a ZIP when there are several. The accountant’s own template and an import test in Siigo are still pending, so it stays in beta.

Excel exports. Inventory, movements by date, purchases, sales and recipes, with real numbers, dates and COP formats. Administrators only.

Backups. A consistent daily copy through the SQLite API, with an integrity check and 14 days of rotation. On Windows, a scheduled task at 12:30 and at login, plus a SHA-256 verified copy to a synced folder (OneDrive or Drive). The restore command asks for confirmation, validates the file and revokes sessions. An automated test creates data, backs up, deletes movements and restores the exact content.

POS import. The administrator uploads the POS’s CSV or XLSX (up to 5 MiB), maps columns once per location, matches products with saved equivalences, reviews a preview (totals, discounts, negatives, products without a recipe, rejected and duplicate lines) and confirms in one transaction. Each line gets a fingerprint so it cannot be imported twice, and the whole import can be undone with adjustment movements.

Out of scope, on purpose. Tax e-invoicing and the POS itself stay with a certified provider. No payment processing. One installation per company.

Demo and status

• Status: working demo, ready for a pilot. Fictional data.
• Tests: 396 automated tests passing.
• Security: two adversarial reviews. The latest, on October 19, 2026, found nothing critical or high. Medium and low findings were fixed.
• Still to do: an install rehearsal on the first client’s real machine, and measuring the invoice agent on real invoices.

The proposal for the first client starts with one pilot location and 30 days of measurement. Those numbers decide whether it rolls out to the rest.

What I learned

• An honest review beats a pretty proposal. My first proposal promised login, backups and export the product didn’t have yet. An adversarial review caught it before it went out. I built those pieces before promising them.
• Saying what you don’t do builds trust. When I explain that I’m not replacing the POS or e-invoicing, owners relax. They know I’m not asking them to change everything.
• The client’s data rules. Accounting formats, closing rules and recipes get confirmed with their people. I don’t guess.

What broke and how I found it

• My first proposal promised things the product didn’t have. Login, backups and Excel export were in the proposal before they existed in the code. An adversarial review of the proposal (October 7, 2026) caught it before it went out. I built those pieces, with tests, before promising them again.
• The security review found open doors. On October 12 the review found no limit on HTTP body size, no per-location authorization and sessions that survived logout. Fixed: 256 KiB request limit, each user sees only assigned locations, sessions revoked on logout and on any change of role or password, progressive wait on failed logins. Evidence before and after is in the project.
• The POS import and the invoice agent had seven findings. A second adversarial review on October 14 found seven problems in file handling (size, type, decompressed rows). All seven fixed, with 33 regression tests.

Same pain in your business?

If your inventory lives in a spreadsheet or a notebook, or your daily close depends on one person, let’s talk. I’ll show you the demo on your case before quoting anything.

Message me on LinkedIn