Skip to content
MultiPOSRetail operations

Multi-business · Multi-branch · Multi-currency

One ledger for every branch you open.

MultiPOS is a point of sale with a real operational spine behind it — transactional inventory, procurement, receivables and an immutable stock ledger, isolated per business at the database itself.

  • No card to start
  • Self-host or managed
  • Your data stays yours
1transaction
Sale, payments, balances and ledger commit together
0duplicates
Retried submissions resolve to the same sale

Built on

Isolated per business · Immutable stock ledger · No duplicate sales on retry

Read the documentation →

One system

Four surfaces, one set of records

The till, the back office, the public catalogue and the operator control plane are different views of the same database — not four products that have to be reconciled at the end of the month.

  • Cashiers

    Till

    Register open and close, checkout, tenders, receipts and cash variance.

  • Managers & buyers

    Back office

    Inventory, procurement, orders, receivables, reporting and settings.

  • Customers

    Storefront

    A public per-store catalogue reading the same products as the till.

  • Operators

    Control plane

    Tenant lifecycle, feature flags and audit, behind separate credentials and MFA.

Where systems usually fail

The three places retail software breaks

Duplicate sales, stock nobody can explain, and credit that ages out of sight. Each one is a design decision, so each one was designed for.

The till

A checkout that cannot charge twice

Most point-of-sale trouble starts with a sale that half-committed. MultiPOS submits checkout with an idempotency key and writes everything the sale touches inside one database transaction.

  • Retried submissions resolve to the same sale
  • Sale, payments, balances and ledger commit or roll back together
  • Partial and credit tenders settle against the customer account
  • Registers open and close with counted cash and recorded variance

One checkout writes

sales
1 row
sale_payments
1–n rows
inventory_balances
updated
stock_ledger
append-only

The warehouse

Stock you can explain, line by line

A balance is never typed in. It is the sum of an append-only ledger, so any figure on any screen can be traced back to the receipt, adjustment or sale that produced it.

  • Immutable ledger entry on every movement
  • Opening stock, then adjustments with recorded reasons
  • Warehouses and stock locations per branch
  • Optional batch, serial and expiry capture at receiving
  • XLSX and CSV ledger exports straight from the backend

Movement sources

Goods receiving
+ accepted qty
Point of sale
− sold qty
Adjustment
± with reason
Pickup handover
− at collection

The ledger

Credit that does not quietly become bad debt

Selling on account is the easy part. MultiPOS carries the rest: ageing, allocation, cases, promises and reminders — all against the same records the till wrote.

  • Credit limits and payment terms per customer
  • Payments allocated to the oldest sale first
  • Branch-owned collection cases, promises to pay and disputes
  • Configurable overdue rules with consent-aware delivery
  • Account receipts reconciled into the cashier's open register

Receivable lifecycle

Credit sale
due date set
Overdue
rule queues reminder
Collection case
promise to pay
Receipt
FIFO allocation

Isolation

Your business cannot see another one. Not by convention — by construction.

Tenant tables force row-level security in the database itself, and the application runtime connects as a role that has no authority to bypass it. A missing filter returns nothing instead of somebody else's sales.

How isolation works
  • Isolation in the database, not the query

    Tenant tables force row-level security in the database. The runtime connects as a non-owner role that cannot bypass it, and tenant context is set per transaction. A forgotten WHERE clause returns nothing rather than someone else's sales.

  • Sessions the browser cannot read

    Authentication is a JWT delivered in an HttpOnly, SameSite cookie. There is no token sitting in local storage for a script to pick up.

  • A control plane that is genuinely separate

    Platform administration runs with its own administrators, its own JWT audience and signing key, and mandatory TOTP. A business administrator account cannot authenticate to it at all.

  • Immediate authority revocation

    Withdrawing access takes effect on the next request rather than whenever a token happens to expire.

Connected

Talks to what you already use

Mobile money settles against the sale it belongs to. Fiscal transmission sits behind an outbox so an unreachable tax authority never blocks a checkout.

  • M-Pesa via Lipana

    STK push, signed webhooks, reconciliation

  • KRA eTIMS

    Configuration and transactional outbox

  • Outgoing email

    Statements, reminders and document delivery

  • Webhook messaging

    Provider-neutral reminder delivery

Storefront

Sell online from the same shelf

Every business gets a public, server-rendered catalogue at its own slug, branded to the store and reading the same product data the till sells from. No export, no sync job, no second stock figure to reconcile.

How storefront addresses work

Pricing

Priced per branch, not per feature

Tenant isolation and the audit log are in every plan. They are not the reason to upgrade.

  • Single branch

    KES 4,900

    per branch / month

    One shop, one register, the full operational core.

  • Multi-branch

    KES 12,900

    per business / month

    Several branches under one ledger, with the buying side included.

  • Self-hosted

    Talk to us

    annual licence

    Your cluster, your database, your compliance boundary.

Questions

Before you ask

Still unsure? Send us the question and a person will answer it.

Can one person run several businesses from one login?

Yes. Accounts are global and hold membership in multiple isolated businesses. You sign in once, switch business from the app, and carry a separate role in each. The data behind them stays isolated at the database level.

What happens when the network drops mid-sale?

Checkout submission is idempotent. A retried submission resolves to the same sale rather than a duplicate, and the sale, its payments, inventory balances and stock ledger entries are written in a single transaction — so you never end up with a payment recorded against stock that never moved.

How is one business kept out of another's data?

Row-level security is forced on tenant tables, and the application runtime connects as a role that cannot bypass it. Tenant context is set per transaction. Isolation is a property of the database rather than a convention the application code has to remember.

Do you support credit customers and collections?

Customers carry credit limits and payment terms. Receivables track due dates with oldest-sale allocation, and overdue accounts can be worked as branch-owned collection cases with promises to pay, disputes, and configurable reminder rules.

Is stock tracked by batch, serial or expiry?

Optionally, yes — captured at goods receiving alongside supplier delivery-note references, accepted and rejected quantities and rejection reasons.

Can we self-host?

Yes. The whole stack runs in containers locally, and production cluster configuration is maintained in a separate deployment repository with immutable, promoted image tags. We share the full platform detail with self-hosting customers on request.

Get started

Open your second branch without opening a second system.

Bring your products, staff and customers across in an afternoon. We will walk you through it.