Platform

Purchasing, stock, sales and accounting on one ledger

Purchasing, inventory, sales and accounting are four stations on one record, not four systems reconciled by hand. A purchase order becomes a goods receipt, the receipt sets the cost the stock carries, the sale issues at that cost, and the journal posts with the VAT line already attached. Nobody retypes anything, because there is nothing to retype.

Why do my systems not match at month end?

Because there are four of them, and a spreadsheet between every pair. Each one is internally consistent and none of them agrees with the others, so month-end becomes an argument about which number is real. The reconciliation is not a missing feature. It is the integration you already paid for, performed by a person.

fig. 01 · Four systems, and a spreadsheet between every pair: the reconciliation is the integration you already paid for.

What does one ledger actually mean?

One record, read from four places. Purchasing, inventory, sales and accounting are stations on it rather than systems beside it. We build to that standard from the schema up, and the till we wrote ourselves runs on it too: the standard is the commitment, not a vendor's roadmap.

fig. 02 · Purchasing, inventory, sales and accounting are four stations on one record, not four systems reconciled by hand.

How does a single transaction move through it?

PO-1042 is raised against a supplier with a real lead time. GR-1042 receives it, and that is where custody changes and stock first moves. The bill matches three ways: order, receipt, invoice. SO-2841 sells the unit, and stock issues at the cost it landed at rather than the cost someone typed. INV-2841 raises, and the journal posts with the VAT line and the KHR/USD pair already on it.

That is the whole argument, and it is worth reading twice: at no point did a number leave one system and get re-entered into another. The trail from the monthly return back to the purchase order is one query, not an afternoon.

A long warehouse aisle, shelves of boxed stock on both sides

Where does the till fit?

Scale POS writes into the same record. A sale at the counter is already the accounting entry, not a file exported nightly, not a summary someone keys in on Monday. It ships today and runs in real shops.

fig. 03 · Scale POS writes into the same record as everything else, so a sale at the counter is already the accounting entry.

What this is not

Not a SaaS subscription, and not a product licensed from Scale. Not one vendor's stack either: we resell nothing and take no referral fees, so we build what your operation needs rather than configure what somebody else sells. And not a shipped AI system: see below, in plain words.

What is not built yet: demand forecasting

Forecasting is at design stage. No client runs a model against their data on Scale today. Stage: design. Not built, not in beta, not shipped as a product.

The reason it is on this page at all is architectural. Forecasting needs sales history, and we build the ledger that produces it first. One schema means a forecasting layer has one place to read from when it ships. What we do sell today is different and worth naming: we build forecasting and scoring models to order, on your data, as an engagement. We do not sell a forecasting product, and nothing on this ledger runs one.

fig. 04 · Forecasting is at design stage: the ledger is the one place a model would read from, and today nothing reads from it.

Where this attaches

Phnom Penh's riverfront towers at night, lights on the water

Talk to us

Paid discovery maps your purchasing, stock, sales and accounting onto one ledger, and comes back with a fixed-scope build.