The short answer
ERP software works by recording every business event as a document on one shared database. Each document — an order, a purchase order, a goods receipt, an invoice — has a header, line items and a status; each is created from the document before it and carries a reference back to it; approvals move it through a lifecycle from draft to released to closed; and every physical stock movement posts one common ledger. Because sales, purchase, stores, production, quality and accounts all read and write the same records, the numbers agree by construction — there is no synchronisation step that can fail.
That is the whole idea. The rest of this guide unpacks each part of the machinery using Fast ERP as the working example, because its internals are unusually clean: one universal document engine for commercial paperwork, one store engine for stock, and a database-driven role menu deciding who sees what. For the business-level view of the same system, start at the pillar, what is ERP software?
Everything is a document: header, lines, status
Open any transaction in a manufacturing ERP and you find the same anatomy. A header carries the document number, its type, its date, the party involved and its current status. Under it, line items carry the detail — item, quantity, rate, tax — one row per item. Around them hang the supporting records: references to other documents, notes, addresses, contacts and charges.
In Fast ERP this is literal: quotations, order acceptances, purchase requisitions, purchase orders, invoices and delivery challans are all rows in the same universal document engine, distinguished by a document code — OA for order acceptance, PR for requisition, PO for purchase order, IN for invoice, DC for delivery challan, WO for work order. Stock documents follow the same pattern on their own engine, with codes for receipt, transfer, issue, reservation, WIP, finished goods and kitting.
Why does this matter to you rather than just to programmers? Consistency. Every document behaves the same way — the same numbering, the same approval mechanics, the same audit trail, the same printing and reporting — so learning one module teaches you the grammar of all of them. And a new document type is a new configuration, not a new subsystem.
Documents reference documents: the chain of custody
The second principle is that documents are born from other documents. A quotation is raised against an enquiry. An order acceptance is created from the approved quotation. The purchase order references its requisition; the goods receipt is recorded against the purchase order; the supplier bill is matched to the receipt; the invoice descends from the dispatch, which descends from the order.
Each of those links is stored, which yields two things disconnected tools can never give you. First, derived quantities are automatic: pending-order quantity is ordered-minus-received, read off the chain; order-versus-invoice reconciliation is a report, not a project. Second, traceability is free: from a supplier lot you can walk forward to the customer invoice, or from a complaint walk back to the goods receipt that admitted the offending material. The quote-to-cash and procure-to-pay guides walk these chains stage by stage.
The status lifecycle: draft to closed
Every document carries a status, and the status is not decoration — it decides what the document is allowed to do. The canonical lifecycle in Fast ERP runs:
| Status | Meaning | What it permits |
|---|---|---|
| Draft | Entered but not yet vetted | Editing; no effect on the business |
| Checked | Vetted by a second pair of eyes | Ready for approval; still no downstream effect |
| Approved / Released | Authorised by the responsible role | Acts — drives production, commits spend, ships goods |
| In-progress | Being executed | Partial receipts, partial dispatches accumulate against it |
| Completed | Fully executed | Quantities exhausted; ready to close |
| Short-closed | Deliberately ended early | Remaining quantity cancelled with a decision on record |
| Cancelled | Withdrawn | Kept on record; excluded from live figures |
| Closed | Finished and locked | History; reporting only |
Quality adds its own disposition statuses at inspection — accepted, rejected, accepted-under-deviation — and pre-sales tracks its own pipeline stages from enquiry received to order received. The point everywhere is the same: a document does nothing until it is released. An unapproved PO commits no money; an unreleased OA drives no production. Status is what turns record-keeping into control.
Approvals: how control is enforced, not requested
Approvals in an ERP are built into the document flow rather than bolted on as email. Pending queues — quotations awaiting approval, requisitions awaiting check, purchase orders awaiting release, supplier bills awaiting matching — sit on the responsible role's screen until acted on. The approval itself is a status change, made by a user whose role has the right to make it, and recorded with their identity and timestamp.
This is why auditors like ERPs and why owners can delegate without losing control: the rule "no purchase without an approved requisition" is not a policy people are asked to follow — it is the only path the system offers. The benefits guide covers what this discipline is worth commercially.
Prefer to see the machinery running?
In a 30-minute demo we create, check, release and execute a live document chain — order to invoice — so you can watch statuses, references and the stock ledger do their work.
One stock ledger underneath everything
Physical reality gets its own engine. Every stock movement — a goods receipt from purchase, a transfer between locations, a material issue to production, a reservation against an order, work-in-progress, a finished-goods transfer, a kit, a dispatch — is a stock document posting the same ledger. Underneath, stock is tracked at the level that matters: by lot (with production and expiry dates where relevant), by bin location, with an append-only history of where each lot has been and a running balance per bin.
The consequence is that "how much do we have, and where?" has exactly one answer, and it is current. Valuation, ABC analysis and slow-moving reports in the inventory module are computed from this ledger, which is why they can be trusted — they are not a parallel record anyone maintains; they are arithmetic over what actually moved.
Masters bind it together
Documents do not carry their own copies of item and customer details — they bind to masters. The item master supplies the code, description, units of measure, tax group, prices and stock levels; the party master supplies the customer or supplier, their addresses, contacts and GST registration; account, tax, UOM and resource masters supply the rest. Enter a party's GSTIN once and every invoice to them carries it; fix a tax group once and every future document computes correctly.
This is also why master data quality decides implementation success — a theme the implementation guide returns to at length, and the reason the module map puts masters first.
Roles, rights and the menu you see
An ERP has its own login, separate from the network's, because it needs to know who is acting to enforce what they may do. In Fast ERP the menu itself is built from the database per role: a stores operator logs in and sees store transactions; a purchase officer sees the PE-PR-PO chain; a quality engineer sees inspections and gauges; management sees dashboards across all of it. Every page checks the user's session before serving, and rights extend beyond visibility to action — seeing purchase orders is a different right from releasing them.
A platform-level consequence worth knowing: because the menu is data, which modules a deployment exposes is configuration. The eleven other Fast products are exactly this — role-menu profiles of the same platform — which is what makes the start-small-and-grow path native rather than a migration.
The audit trail: who did what, when
Underneath the documents, every write is recorded — inserts, updates and deletes captured with the user, the screen and the timestamp, alongside a log of user activity. Combined with document status history, this answers the questions that matter after the fact: who released this order, who changed this rate, who cancelled this receipt, and when.
For a proprietor this is delegation insurance; for a customer or statutory audit it is evidence on tap. Nothing needs to be reconstructed from memory, because the system never forgot.
Where reports and dashboards come from
Because everything above writes one database, reporting is reading, not gathering. Pending-PO and pending-PR lists, on-time purchase performance, order-versus-invoice reconciliation, BOM costing, inspection MIS, machine loading, stock valuation and party-wise GST are all queries over the live records — Fast ERP ships some 90+ reports and around 27 dashboards on this principle, with exports to PDF and Word where paper is needed.
The same foundation is what makes an AI layer honest: Dhruv AI answers plain-English questions and clusters quality remarks over the same single source of truth, rather than over an export that was stale before it was analysed.
Where integrations fit
Between its own modules an ERP needs no interfaces — that is the point of one database. Integrations exist at the edges, where the ERP meets other systems and the physical world: Tally receives purchase vouchers from goods receipts, sales vouchers from invoices and stock journals from transfers; GST and statutory tooling covers HSN import, C-Form and e-way-bill data; barcode and QR labels print to thermal printers for GRN, item and pallet labelling; email, SMS and WhatsApp carry approvals and alerts outward; and KooKoo IVR telephony logs calls against complaints and enquiries.
Each integration is one-directional and document-driven — a released document generates its voucher, label or message — so the edges inherit the same discipline as the core.
One order through the machinery
Put the layers together and follow a single order through them:
The absence you should notice
At no point in that walkthrough did anything get exported, imported, synced or re-typed. There is no interface between sales and stores, no batch job between purchase and accounts, no spreadsheet bridging production and planning. Every failure mode those joins create in a disconnected stack — stale copies, missed updates, numbers that disagree — is absent not because the software is careful, but because the joins do not exist. That is the deepest answer to "how does ERP software work": it works by making the second copy structurally impossible.
Frequently asked questions
How does ERP software work?
An ERP works by recording every business event as a document — an order, a purchase order, a goods receipt, an invoice — on one shared database. Each document has a header, line items and a status; documents are created from the documents before them; approvals move them through a lifecycle from draft to released to closed; and every stock movement posts one common ledger. Because all modules read and write the same records, the numbers agree without any synchronisation between systems.
What is a document status lifecycle in an ERP?
Every document moves through controlled states — typically draft, checked, approved/released, in-progress, completed, short-closed or cancelled, and closed. A document has no effect on the business until the right role releases it: an unapproved purchase order commits no spend, an unreleased sales order drives no production. The lifecycle is what turns records into internal control.
How are documents linked together in an ERP?
Each document carries a reference to the one it came from: a purchase order references its requisition, a goods receipt references the purchase order, an invoice references the dispatch and the order. Following the references in either direction gives full traceability — from a supplier lot forward to the customer invoice, or from an invoice back to the enquiry that started it.
What is role-based access control (RBAC) in an ERP?
RBAC means each user logs in to a menu built from their role's rights, so a stores operator sees store transactions, a purchase officer sees the purchase chain, and only authorised roles can approve or release documents. In Fast ERP the menu itself is driven from the database per role, every page checks the user's session, and every write is captured in an audit trail with user activity logging.
Does an ERP need interfaces between its modules?
No — and that is the point. Because sales, purchase, stores, production, quality and accounts are views over the same database, there is nothing to interface, export or synchronise between them. External integrations still exist — Fast ERP posts vouchers to Tally, sends email/SMS and WhatsApp alerts, and prints barcode labels — but between its own modules the data is simply shared.