Inventory system architecture, drawn honestly

The key facts

• Layer 1 — the record: products, quantities per location, batches, costs. Everything else reads and writes it.
• Layer 2 — movements: receipts, issues, transfers, adjustments — the only things that ever change the record.
• Layer 3 — workflow: purchasing, orders, picking, counts, invoicing — the reasons movements happen.
• Layer 4 — integrations: accounting (Xero, MYOB), ecommerce (Shopify by webhook), and read access (public REST API, MCP endpoint).
• BSimple is cloud, browser-based, multi-location, with tenant isolation and an audit trail across the layers.

The four layers, drawn

Picture the architecture as four horizontal layers, each depending on the one below:

The record sits at the bottom: one product table with quantities per location, multi-level units (boxes into sleeves), batch/lot numbers with expiry, and costs. If this layer is a spreadsheet, every layer above inherits its fragility — which is why "the architecture" of most small businesses is really a story about this one layer.

Movements are the only writes: goods received, stock issued, transfers between locations, adjustments from counts. An architecture is honest when every quantity change is a movement with a user and a timestamp — the audit trail — rather than a silent edit.

Workflow sits above: reorder levels raise purchase orders, orders drive picking and packing, counts drive adjustments, approved orders become invoices. The workflow layer is where an inventory system stops being a list and starts being operations — purchasing belongs to this layer.

Integrations are the edges: invoices pushed to Xero or MYOB with payment status mirrored back, Shopify orders imported by webhook, and read projections exposed to your own tools through a public API.

How BSimple is actually put together

We build BSimple, so weigh that — and the honest description is short. It is cloud software in the browser: no install, multi-location, tenant-isolated, with an audit trail on the record. The workflow layer carries inventory, purchasing, orders, the customer portal, recipes and production, stocktakes and invoicing on one dataset. The integration layer pushes approved invoices to Xero or MYOB (payment status mirrors back), imports Shopify orders by webhook for delivery slips and pick/pack, and exposes a public REST API with scoped keys — read projections for suppliers, locations, reorder levels, stocktakes, purchase orders and transfers — plus an MCP endpoint for AI-assistant access.

What the diagram deliberately does not contain: MRP scheduling, HR, payroll or a storefront. Boundaries are architecture too — the accounting system stays the system of record for compliance, and BSimple is the operations layer between spreadsheets and an ERP.

Using the diagram to evaluate systems

The diagram is a checklist. Ask each vendor the same four questions: where does the record live (and who can edit it silently); are movements real transactions with an audit trail; does workflow actually drive movements (does a purchase order update stock on receipt); and where are the integration edges (accounting, ecommerce, API). A system weak in any layer leaks work to spreadsheets at exactly that layer.

The use-case diagram guide sketches the same architecture from the actors' side, and the inventory management guide describes the record and workflow layers as BSimple runs them. The fastest evaluation remains the free trial — one movement from each layer, on your own products. For the data layer in detail, the database design page and the LLD companion go one level down.