Architecture

The Snapshot Style System

BasilBook freezes data at the moment it happens. Rename a product, change a salary, switch currencies — your historical records stay exactly as they were. This is what makes BasilBook audit-ready by design.

Why snapshots matter

Most restaurant software stores references — a sale points to a product, and when you look up the sale, it pulls the product's current name and price. This means changing anything today silently rewrites your history. BasilBook takes a different approach: every transaction captures the data as it was at that exact moment.

Reference-based (most software)

Sale → points to Product #42 → looks up current name "Premium Beef Pho". But in February it was called "Beef Noodle". Your February report now shows a product that didn't exist yet.

Snapshot-based (BasilBook)

Sale stores productName: "Beef Noodle", currency: "USD", price: $5.50 — frozen forever. Rename the product, change currencies, update prices — this record never changes.

Transaction Currency Freezing

Every sale and purchase stores the currency at the moment it happens. If your restaurant switches from USD to KHR next month, all your past records still show the original currency. No retroactive confusion.

sales_transactions.currencypurchases.currency

Without snapshots: Most systems store a reference to the org currency. When you change it, all old reports shift — breaking your historical financials.

Product Name Preservation

When a sale is recorded, the product name is frozen on the transaction. Rename "Beef Noodle" to "Premium Beef Pho" — your February reports still say "Beef Noodle" because that's what was sold.

sales_transactions.productName

Without snapshots: In systems that use only foreign keys, renaming a product retroactively changes every historical receipt and report. You lose the original context.

Recipe Versioning

Recipes are never overwritten. Each change creates a new version with an effective date. Your December food cost analysis uses December's recipe, even if you changed ingredients in January.

standard_recipes.versionstandard_recipes.effectiveFromstandard_recipes.effectiveTo

Without snapshots: Other platforms overwrite recipes. Once you update a recipe, all historical cost calculations change retroactively — making past reports unreliable.

Payroll Salary Snapshots

Each payroll line captures the monthly salary and staff name at that point in time. Give someone a raise — their past payslips still show the old salary. Exactly as it happened.

payroll_lines.monthlySalarypayroll_lines.staffNamepayroll_lines.daysWorked

Without snapshots: Systems that pull salary from the employee record recalculate all past payroll when you update a salary. Your January payroll suddenly shows March numbers.

Per-Channel Price Isolation

Each delivery platform has its own price per item. Grab price changes don't affect your dine-in price, and importing a Grab report doesn't overwrite your FoodPanda pricing.

sale_item_prices.channelsale_item_prices.price

Without snapshots: Most POS systems have one price per item. When you import delivery data, the price gets overwritten with the delivery price — breaking your dine-in pricing.

Purchase Price Snapshot

Every purchase line captures the unit price at the time of purchase. If your vendor raises prices next week, your February purchase records still show what you actually paid. Cost calculations stay accurate.

purchase_lines.unitPricepurchase_lines.lineTotalpurchases.totalAmount

Without snapshots: Systems that reference item cost from the current catalog retroactively change historical purchase values when prices update — corrupting COGS calculations and margin reports.

Sales Amount Freezing

Each sale transaction freezes the gross amount, discount, and net amount at the time of sale. Price changes to menu items never affect past sales records.

sales_transactions.grossAmountsales_transactions.discountsales_transactions.netAmount

Without snapshots: Some systems recalculate sale totals from current item prices. A price increase today makes last month's revenue look higher than it actually was.

Immutable Stock Ledger

Stock is never edited directly. Every movement — purchase, recipe consumption, waste, stock count adjustment — is a separate entry with a reference to its source. You can always trace why stock changed.

stock_movements.referenceIdstock_movements.referenceTypestock_movements.movementType

Without snapshots: Many inventory systems let you manually edit stock balances. This destroys the audit trail — you can't tell whether stock disappeared due to waste, theft, or a data entry mistake.

Design Principles

The rules behind the system

Never overwrite, always version

Recipes, prices, and configurations create new versions instead of modifying existing records.

Freeze at transaction time

Currency, product names, salary rates, and staff identities are captured when the event occurs — not looked up later.

No direct stock editing

All inventory changes flow through typed movements (purchase, waste, consumption, adjustment) with source references.

Separate stable keys from display names

POS usernames are immutable import keys. Display names can be edited without breaking import matching.

Account resolution, not duplication

Items link to their GL accounts. Journal entries are generated from these links — the accounting logic is never duplicated per transaction.

Full audit trail

System logs capture before/after snapshots of every import, price change, and name update. Nothing is lost.

Your data deserves better than references

BasilBook's snapshot architecture means your financial records are always accurate, always auditable, and never silently rewritten.