Home OverviewBusiness Management System Order to cash Purchase to pay The other three lanes Build state All products
Get in touch Build state

Products › Business Management System

Order to cash.
Purchase to pay.

An ERP built around how an SME actually runs

Five lanes, one chain of records. A quotation becomes an order, an order becomes a delivery, a delivery becomes an invoice — and the money questions read off that same chain rather than a spreadsheet kept beside it.

Stock on hand, unit cost and ageing are derived from movements — never typed.

5
lanes, one chain
47
named steps, each on a screen
1
ledger behind every report
0
figures typed twice
Demo video goes here Drop the file at assets/erp-demo.mp4 — 16:9, 1920×1080, H.264. Autoplays muted on loop; keep it under roughly 8 MB and 30 seconds.

One quotation, followed all the way to a collected payment.

Selling — order to cash

Every document carries the last one’s lines. Nothing is retyped between a quotation and an invoice, and nothing is advertised as agreed until the customer’s own paperwork says so.

  • A revision is a new version, not an edit. v2 carries every line and supersedes v1 the moment it is issued. v1 is never edited, so what the customer actually saw is still on the record.
  • A discount past a seller’s limit becomes a draft. Not a warning they can dismiss — the line saves as a draft for somebody whose limit actually covers it.
  • “Awaiting customer PO” is a view, not a status. Accepted with no order yet, and how long it has been waiting. A customer marked requires-PO cannot have an order confirmed without one, and the composer says so.
  • A delivery can come back. Every movement is reversed and the order owes it again — because a returned delivery is a stock event, not a note in a comment field.
  • Five standing reminders per invoice, derived from the terms and each recorded once by a database constraint rather than by a job that might run twice. Raising a dispute quiets them.
  • Every ending is a recorded one. Lost with a reason, closed short with a reason, disputed with grounds, written off to bad debt with a reason and posted, or credited line by line.

Cost and margin are withheld by the server, not hidden by the interface — a money-blind role cannot see them even if it asks. A seller sees their own customers; the owner sees everyone.

Buying — purchase to pay

A bill cannot be paid until it agrees with the order and the goods. The three documents are checked against each other, which is the whole point of running procurement in one place.

  • The store never sees a price. A purchase request picks items by category with no prices on it at all, so whoever is asking is not anchored by what it costs.
  • The recommendation is overridable, and states its basis. Comparison runs line by line with a supplier each, so a split award is normal rather than a workaround.
  • Approving a purchase order is not sending it. Preview, then approve if you are authorised, then send or download — three separate acts, because signing off and issuing are different decisions.
  • Awaiting delivery is a standing item every day until something arrives — not a report someone remembers to open.
  • A payment run posts both sides. Debit accounts payable, credit bank — AP and the bank move together, so the two can never disagree about the same payment.

Department personnel see their own vendors; the department owner sees all of them. Scope is a property of the record rather than a filter someone chooses.

Three more lanes

Not everything a business pays for arrives on a pallet, and not every question is answered by a document.

Expenses & payments — no stock, so no GRN+
Raised by a department, approved, then paid like any other liability — but the kind of thing it is matters. An expense hits the P&L and the cash flow; a payment — a loan, hire purchase, SST, EPF — hits the cash flow only. And the kind is enforced: a request whose own words say loan or EPF cannot claim to be an expense.

Recurring, fixed: cost centre, vendor, due date, frequency, amount. The agreement, a start and an end are required — a fixed template without them fails the import rather than sitting there half-defined.

Recurring, variable: a budgeted amount stands in until the real bill arrives, and the instance reads No bill yet, in red, until it does. Overdue means billed and unpaid. The two are different failures and the schedule says which one you have.

The schedule runs from three months back to each agreement’s end, with status derived per row — and what is not yet due is blank, not zero, because zero is an answer and blank is the absence of one.
Inventory — by store, and no ringgit in the lane+
A trading firm has one store or two. A factory has three — raw, production, finished — each a store in its own right with its own count and its own adjustments.

Stock on hand is calculated per store from movements. It is never typed. Stock in comes from a supplier; stock out goes to a customer. A stock take is per store and the variance is journaled with a reason. An adjustment is reason-coded and journaled too.

Units are handled properly: bought by the carton, sold by the piece, with the selling cost derived from the vendor’s cost divided by the units in the carton rather than entered by hand.

And the whole lane is money-blind. No ringgit figure reaches it — the warehouse works in quantities, which is both simpler for them and safer for you.
Finance — where the money questions live+
AR ageing answers who owes you and for how long. AP ageing answers who you owe and by when. Collections is a Finance workspace for the chasing, the promises and the outcomes. Payments covers what went out, and the unallocated ones that came in.

A customer statement of account is the customer’s copy of the same ledger — not a separately maintained document that can drift from it.

e-Invoice: MyInvois validation state travels on the invoice itself rather than living in a separate submission log.

A 13-week cash runway is computed from what is expected in and expected out. See the build state below for what in this lane is designed rather than finished.
Why it is one chain and not five modules+
Every step in the process names the screen it happens on, and the application refuses to start if a step names a screen that does not exist. That sounds like an implementation detail; it is actually the reason the flow above is accurate. A process map that is generated from the code cannot describe a workflow the software does not have.

The same discipline runs through the data. Stock on hand is derived from movements. Unit cost is derived from the purchase cost and the pack size. Ageing is derived from the invoice and its terms. Reminders are derived from the invoice date. None of them is a field somebody maintains, which is why the reports cannot disagree with the documents.

Where this actually is

Forty-seven steps, each with a build state we track rather than round up. Here it is, honestly, so a conversation starts from the right place.

15
Live Working and walked end to end by an automated suite, not demoed by hand.
25
Partly built The step works; something named is still outstanding. Each one says what.
7
Designed, not built Specified and scheduled, with no screen yet. Named below rather than implied.

The seven not yet built: the cash flow statement, the income and expense statement, both budgets, bank statement import, bank reconciliation, and production value-add for factories. The SST statement is deliberately held until the treatment is verified with RMCD — we would rather ship it late than ship it wrong.

Also still to come across the partly-built steps: document uploads on the six steps that want one, part payments and multi-invoice settlement, store-to-store transfers, and e-Invoice submission with a register of what is pending. There is no customer portal — a quotation is sent as a PDF, and a login for customers waits until one asks for it.

Nothing in the five lanes above describes a step that does not exist. What is unfinished is on this list.

Derived, not maintained.

Three properties that decide whether an ERP is trusted a year in or quietly worked around.

Every figure is computed

Stock on hand, unit cost, ageing and reminder dates are all derived from the records underneath them. No second set of numbers exists to fall out of step.

Scope is enforced on the server

A money-blind role cannot retrieve cost or margin, whatever the interface asks for. Sellers see their own customers, departments see their own vendors.

Every ending has a reason on it

Lost, closed short, disputed, written off, credited, adjusted, counted short — each one records why, so the exceptions are as auditable as the happy path.

Frequently asked questions

How does the inventory module handle stock across more than one store or warehouse?+
Stock on hand is calculated per store from movements and is never typed in. A trading firm might run one or two stores and a factory three (raw, production, finished), each with its own count and its own adjustments. The whole inventory lane is money-blind: no ringgit figure reaches it, and the warehouse works in quantities only.
Is a supplier bill checked against the purchase order and the goods received note before it can be paid?+
Yes. A bill cannot be paid until it agrees with the purchase order and the GRN; the three documents are checked against each other. Upstream, a purchase request carries no prices, and a count difference on the GRN needs a reason.
Is approving a purchase order the same as sending it to the supplier?+
No. Preview, approve (if you are authorised) and send or download are three separate acts, because signing off and issuing are treated as different decisions. Approval goes nowhere until someone with the right puts their name to it.
Can I stop sales or warehouse staff from seeing cost and margin?+
Yes. Cost and margin are withheld by the server rather than hidden by the interface, so a money-blind role cannot retrieve them whatever the interface asks for. A seller sees only their own customers and the owner sees everyone; department personnel see their own vendors. Scope is a property of the record, not a filter someone chooses.
Which steps are designed but not built yet?+
Of the 47 named steps, 15 are live, 25 are partly built, and 7 are designed with no screen yet: the cash flow statement, the income and expense statement, both budgets, bank statement import, bank reconciliation, and production value-add for factories. The SST statement is deliberately held back until the tax treatment is verified with RMCD.
Can it submit e-Invoices to MyInvois, take part payments, or move stock between stores yet?+
Not yet. Still to come across the partly-built steps are e-Invoice submission with a register of what is pending, part payments and multi-invoice settlement, store-to-store transfers, and document uploads on the six steps that want one. There is also no customer portal: a quotation is sent as a PDF, and a customer login waits until one asks for it.

Published 9 September 2026 · Updated 9 September 2026 · Written by the TalbotIQ team

Book a walkthrough.

Tell us whether you trade or manufacture, how many stores you count in, and who is allowed to see a margin. We will walk the lanes that matter to you.

0 / 250
Request walkthrough

One chain, five lanes.

Bring a real quotation and a real supplier bill to the call. We will run both through and you can see where they end up.

Malaysia-based team · Response within one business day · No obligation