ERP & Operations Systems

03

One set of books, one view of the truth

The cost of disconnected records is not the extra typing — it is that every department ends up believing a different version of the company. ERP exists to make one connected record: purchases post to stock, orders draw from stock, and both flow to finance, so the question 'what is the actual state of the business' has a single, verifiable answer.

• One connected record — inventory, purchasing, orders and finance share one lineage of transactions, so the stock report, the payables listing and the profit-and-loss cannot tell different stories.
• Every posting is traceable — each financial line carries its operational origin — the purchase order, the delivery note, the sale — so the books are evidence, not assertion.
• The ledger is the core — the balance sheet and the operational records are two views of the same posting universe, not two systems that occasionally agree.
• Periods close cleanly — the month-end close produces reconciled books with a documented trail, so the audit reads like a story instead of an archaeology dig.
• Margin is computed, not claimed — cost, revenue and margin per item and per order are drawn from real inventory movements, so 'how profitable is this line' is a number, not a rumour.
• The bank is the referee — the ultimate test is the bank statement; we build so the books and the bank reconcile, because that is the only proof that matters.

One set of books does not just save effort; it stops the owner from being the last person to learn the truth. That is the whole point of the discipline.

04

Inventory that matches the warehouse

Inventory is where some businesses quietly lose their margin and others quietly double it. The stock record only matters when it matches what is physically on the shelf. We build inventory that moves through real workflows — receipts, transfers, issues and adjustments — so the system's count earns the right to be believed.

• Stock moves with events — goods receipts, sales issues, transfers and adjustments each post inventory movement with their reference, so the count is the sum of real events, not an opinion.
• The count can be verified — a physical stocktake reconciles the book count against the shelf, and every variance is an adjustment with a reason and an approver.
• Units that stay honest — items, units of measure and conversions are modelled so a case and a piece never get added together by accident.
• Costing that is real — average, FIFO or standard cost per item is computed from actual purchase lines, so margin calculations are grounded, not assumed.
• Low-stock as a trigger — reorder points generate purchase suggestions and alerts, so 'we are out of the thing we sell most' stops being a discovery at the counter.
• Negative stock is impossible by design — the system refuses to sell or issue what the record does not hold; the warehouse and the system are forced to agree.

Inventory software is only worth anything if the count on screen is the count on the shelf. We build the movement trails that make that true.

05

Stock across branches and warehouses

A multi-branch business multiplies the inventory problem: stock moves between locations, each branch believes its own truth, and the owner reconciles three partial pictures. We build one inventory model with many locations, transfers between them, and one consolidated truth at headquarters.

• Locations as first-class records — warehouses and branches have their own counts, but one shared item master and one set of costing rules.
• Transfers with a trail — stock moving from Nairobi to Nakuru is a transfer document with dispatcher, receiver and approval, so nobody can explain 'missing' stock with a shrug.
• Variances attributed — transit losses and receipt discrepancies land on the branch responsible with their adjustments recorded, not buried in a global number.
• One consolidated view — headquarters sees the whole network — total on hand, per branch, per warehouse — from one screen, at one moment.
• Branch accountability — each location reconciles its own counts, so a branch that loses stock is identified by the record, not by rumour.
• Reordering respects the network — reorder logic considers demand and stock per location, so the right branch gets the right quantity, not a global average.

Multi-branch does not mean multi-truth. The system gives every branch its numbers and the owner one reconciled set of numbers over all of them.

06

Purchasing and the procurement workflow

Procurement is where margin is made or lost, and where cash quietly leaks when there is no discipline. Every shilling going out should be approved, documented and on record before it leaves. We build the workflow — from request to purchase order to receipt to price — so buying is a managed act, not a habit.

• Purchase requests with a chain — the ask, the justification and the approval live on the document, so spend starts with a decision, not a dash.
• Supplier records with terms — suppliers carry their payment terms, contacts and history in one file, so 'who do we owe and when' is always answerable.
• Purchase orders that bind — the PO carries the agreed prices and quantities, so the receipt and the invoice have a reference they must obey.
• Receipts against the order — goods received match the PO line by line; what was not delivered is visible, and over-delivery is controlled, not wondered at.
• Three-way matching — the receipt, the invoice and the purchase order reconcile before a payment is scheduled, so the classic overpayment route is closed.
• Price history as leverage — what was paid per unit to whom, over time, is a query — because no buyer should negotiate against amnesia.

Procurement software does not slow down a good buyer; it slows down the bad surprise. The discipline turns buying into an auditable, repeatable act.

07

Payables without double payment

A supplier paid twice is cash thrown away; a supplier paid late is a relationship damaged. Payables must be exact: every invoice matched, every payment scheduled, every settlement reconciled against the bank, and nothing paid on a guess. We build payables that are as disciplined as any money movement on a payments platform.

• One record per supplier bill — each invoice lands with its reference, terms and due date, so the payables listing is the source of truth, not a memory.
• Duplicate detection — the same invoice number arriving twice is caught before it is paid, structurally rather than by a vigilant clerk.
• Approval before the payment — scheduled payments pass the chain and carry their supporting documents, so no money leaves without a decision on the record.
• Payment runs with proof — batch runs produce references that reconcile to the bank and the ledger, so 'did we pay supplier X' has a provable answer.
• Ageing that is visible — payables age by days overdue, so past-due obligations are a view, not a phone call someone forgot to make.
• Statements reconciled — the supplier statement is matched to the book record quarterly, so a disputed balance is solved with evidence, not volume.

Payables are where cash conservation is won and lost. We build the workflow so nothing is double-paid, nothing is forgotten, and everything settled reconciles with the bank.

08

Receivables and collections

A sale that is never collected is a gift. Receivables must show the true state of every customer account — what is owing, how old, and what has been promised — and the collection loop has to be machinery, not a monthly scramble with the ledger.

• Every invoice on the account — each customer account carries its invoices, credits, payments and ageing in one place, so the balance is the sum of real documents.
• Ageing by bucket — current, 30, 60, 90-plus days are computed from the dates, so 'who owes us and for how long' is a query, not an argument.
• Statements that generate — customer statements render in one click, so the business and the customer are looking at the same numbers.
• Collections scheduled — follow-ups, reminders and the notes that go with them are scheduled on the account, on the customer's preferred channel, under consent rules.
• Payments tie the invoice — every collection is applied to the invoice or the statement line it settles, so partial payment and part-settlement are explicit state, not guesswork.
• Exact-shortfall honesty — when a customer pays less than due, the system says exactly how much remains and against what, so 'what do I still owe' gets a precise answer.

The best sales team is a receivables process that never lets an invoice grow old quietly. We build the follow-through that makes the sale worth making.

09

Finance: the ledger behind the operation

Every operational event — a purchase, a sale, a stock movement, a payment — should post to a real ledger with real accounts, so the final accounts are the natural output of the business's actual activity rather than an end-of-month reconstruction. Finance is not a separate department's fiction; it is the sum of the operation told as a ledger.

• A chart of accounts that fits — accounts, classes and cost centres model the business's real structure, so the profit-and-loss reads like the company speaks.
• Postings from events, not from re-entry — receipt of goods, delivery of sales and settlement of payments post to the ledger from their source documents, atomically.
• Double-entry by construction — every posting carries its counterpart, so the balance sheet always balances and 'why does this not sum' is not a question that can survive.
• Cost of goods computed — COGS follows the inventory costing method, so gross margin is real before anyone adds 'estimated' to it.
• Period closures with a trail — accruals, cut-offs and closing entries are documented, so the month-end package is a story an auditor can follow.
• The trial balance never lies long — because it is the same record as the operation, a mismatch surfaces in the period it happens, not at the audit.

The ledger is the highest truth of the business because it is woven from every operational thread. We build finance as the ledger of the whole operation, not a parallel kingdom.

10

Bank reconciliation built in

The bank statement is the referee. Books that have never been reconciled against the bank are books that are believed, not verified. We build reconciliation into the flow — matching the system's movements against the statement line by line, surfacing mismatches, and automating it so 'our accounts are verified' stops being a claim and becomes a routine.

• Match by reference — payments, collections and fees match the statement by reference and amount, so each line is proven, not eyeballed.
• The float and the wallet behave — customer money and company money are distinct accounts in the record, so reconciliation never co-mingles pots by accident.
• Totals against the statement — the system's day totals and the bank's statement totals are compared; a mismatch is an incident with an investigation, not a rounding choice.
• Drill to the line — when totals disagree, the system isolates the specific lines, so 'which transaction' gets an answer before anyone starts guessing.
• Scheduled and unattended — a nightly job runs the reconciliation, flags exceptions and pages the right person instead of waiting for a human to remember.
• Expected gaps classified — in-flight settlements and pending clears are classified and parked, so only genuine anomalies reach a human review.

The moment the ledger matches the statement to the shilling is the moment the business is real to itself. We build towards that day from the first posting.

11

Multi-branch without duplicated books

Branches create a temptation: to run separate books for each location, which then must be consolidated by heroic effort every month. We build the alternative — one set of books with branch as a dimension — so the branch comparison is a view, not a merge project.

• Branch as a dimension — one ledger, one chart of accounts, and branch recorded on every posting, so the whole is always coherent while each branch is visible.
• The owner sees the network — turnover, margin, inventory and receivables per branch render from the same records headquarters reads, at the same instant.
• No consolidation monthlies — because the books were never split, there is nothing to add back together; 'consolidated' is just the unfiltered view.
• Transfers and inter-branch flows — stock and cash movement between branches post with both sides, so the balance sheet never double-counts and never loses a leg.
• Comparable branch reports — same definitions, same timing, same currency per branch, so comparing Nakuru and Kisumu is comparing apples to apples.
• Authority per branch — approvals, limits and visibility are scoped by branch, so local managers decide locally and headquarters governs corporately.

Scaling to branches should multiply reach, not multiply record-keeping. One ledger with branch as a lens is how a growing business stays one business.

12

Owners see the company, not each department's claim

Disconnected departments each report their own picture of the business; the owner is left triangulating. An ERP gives owners a management view drawn from the actual operational data — what is being bought, sold, owed and held — so decisions are made on one set of numbers that everyone can verify.

• The owner's dashboard is the floor's data — turnover, margin, cash, stock and receivables come from the same records the operation uses, so they cannot disagree with the floor.
• Cash position is current — money in the bank, money in collections and money owed are computed from live records, so 'how much do we actually have' is a present-tense number.
• Margin before the argument — profitability by product, branch and customer is drawn from real costs, so the 'who is actually making us money' debate has a referee.
• Stock truth aggregated — a single view across all locations tells the owner what is held, where, at what value, and how fast it is turning.
• Decisions on the same numbers — operations, finance and the owner all read one source, so the meeting argues about the future, not about whose spreadsheet is right.
• Drill-down on demand — every headline number opens into its detail, so 'show me why' is the owner's right and one click away.

The owner's superpower is a single set of numbers that the whole company shares. ERP is the machinery that gives it.

13

Management reporting and forecasts

Reports and forecasts matter only if they feed decisions. We build management reporting from the operational data at the cadence decisions are made — daily cash, weekly stock, monthly performance — and forecasts that reason from actual history instead of inherited optimism.

• Reports at decision cadence — the daily, weekly and monthly views are scheduled to the moment the decisions they serve are actually made.
• Cash-flow visibility — projected receipts and scheduled payables combine into a cash view, so 'can we pay that supplier next week' is answerable today.
• Margin by line and by channel — profitability is computed down to product line and channel, so the owner stops subsidising the quiet loser.
• Inventory turnover by item — slow movers and stock traps are visible before they become write-offs, and reorder logic leans on the same data.
• Forecasts that cite their basis — projections are built from actual period patterns, labelled as estimates, and honestly marked as probabilities rather than promises.
• Automated delivery — the report lands in the inbox and on the dashboard on schedule; nobody has to remember to pull the numbers the meeting needs.

A report is only as good as the decision it changes. We build the numbers that survive being checked against the floor and the bank.

14

KRA-ready: receipts, VAT and statutory records

Kenya Revenue Authority compliance is not a year-end panic; it is a consequence of records kept properly all year. Invoices, credit notes, VAT ledgers and stock records should reconstruct the statutory picture in hours, not weeks. We build the receipts side of every sale and the ledger side of every posting so the tax conversation is easy because the truth is inspectable.

• Invoices that carry the numbers — every sale invoice carries its dates, amounts, VAT treatment and references, so a statutory sample traces without a scramble.
• Credit notes trace back — every credit reference the invoice it corrects, so the net sales figure is explainable line by line.
• VAT in the ledger — output and input VAT are tracked in the books, so the periodic return is aggregated from real postings, not reconstructed from memory.
• Receipts on every collection — cash, M-Pesa, card or bank, each payment produces a receipt matched to its invoice, because the customer and the auditor both want the same artifact.
• Statutory records as exports — the ledger, the sales book and the stock movements export in the shape an audit wants, on demand.
• Retention that survives — historical records are archived to legal horizons rather than deleted by tidy instinct.

Compliance stops being scary the day the records stop being a reconstruction. We build the records so the statutory question has a calm, instrumented answer.

15

Money in the ERP: collections and payouts

An ERP with receivables and payables eventually moves real money, and moving real money is a payment-platform discipline. We wire M-Pesa into the operation the way our own platform wires it — collections on the customer's phone, payouts to suppliers on verified rails, and everything landing in one ledger that reconciles.

• Collections on the rail the customer already holds — invoices collect via STK Push, PayBill or Till on M-Pesa/Daraja in the home market, and via PayPal, Stripe, PayStack, cards or bank transfers elsewhere with the same adapters and verification — so the receipt arrives the instant the money is confirmed.
• Payouts to suppliers — supplier payments move on B2B or B2C rails with their approval trail intact, so the payment run is documented end to end.
• One ledger for it all — customer collections, supplier payouts and the fees between them are entries in the same double-entry record as everything else.
• Idempotency on the wire — a retried payment or a redelivered callback is answered with the settled truth; nobody is charged twice by a flaky push.
• Verified before credited — a payment claim is checked against the gateway's own status before the books book it; no money is credited on hope.
• Rate limits and locks — money actions carry per-user windows and row-level locks, so a batch + a walk-in cannot both spend the same available balance.

When the ERP touches real money, it inherits every rule of a payments platform — because we run one, and we hold your books to the same floor.

16

Every rail, one ledger

A business that sells over the counter, online and on terms collects through very different pipes, and the books cannot afford to treat those pipes as separate universes. M-Pesa/Daraja is the rail we know from living on it — STK Push, PayBill, Till, C2B, B2B and B2C — and PayPal, Stripe, PayStack, cards and bank transfers join it as adapters carrying the same guarantees. The ledger does not care which pipe delivered; it cares that the delivery was verified, idempotent and reconcilable.

• Adapters, not special cases — M-Pesa/Daraja, PayPal, Stripe, PayStack, cards and bank transfers implement the same settlement contract, so adding a rail never forks the ledger.
• Credited only on gateway proof — each rail's claim is re-verified against that gateway's own query before the posting lands, so the books never book a hope.
• At-most-once across the wire — idempotency is enforced per adapter, which makes a batch retry, a callback redelivery and a duplicate file produce exactly one posting.
• Mixed rails share one set of locks — row-level locks and rate limits bind the account whether the shilling arrived by STK, card, PayPal or a bank import.
• Statements per pipe, bank as referee — each rail reconciles against its own settlement statement, and the trial balance reconciles against the bank as the final judge.
• KRA-ready across every rail — the receipt, the VAT treatment and the reference trace correctly whether the funds arrived by M-Pesa, card or transfer.

Multi-rail only multiplies risk when every gateway keeps its own private rules. When every pipe lands in one ledger under one discipline, opening a new rail stops being a compliance question and becomes a configuration.

17

Approval chains for every shilling out

Spend controls protect the company from itself more than from anyone else — a busy manager authorising a vendor invoice, a duplicated payment, a PO with the wrong price. Approval chains with thresholds, audit and segregation are the machinery of controlled spend, and they must be fast enough that control never becomes paralysis.

• Thresholds from policy — approval levels come from recorded rules, so the right person decides at the right amount and nothing is routed past authority.
• Evidence in front of the approver — the approver sees the PO, the receipt and the invoice, not a bare 'please approve this payment' button.
• Segregation by design — the requester, the approver and the payer are different hands where policy requires, enforced by the workflow, not by hope.
• Escalation when it stalls — a spend stuck in a queue rises to the next level with its documents, so money neither sits idle nor moves ungoverned.
• Every step on the trail — who approved, when, on what evidence — is recorded, because 'who signed this off' is a question that gets asked forever.
• Audit walks the chain — the payment file reconstructs the full chain from request to settlement, so internal and external audit read it as one story.

Control and speed are allies when the chain is unambiguous. The business that approves in hours and audits in minutes is a business with both.

18

Integrations: the ERP talks to the stack

An ERP that cannot talk to the website, the sales tool, the CRM and the bank becomes the second system of truth instead of the one system of truth. We build the integrations — order feeds, payment flows, statement imports — so the ERP receives reality and disburses one set of numbers to everyone.

• Payments in from everywhere — M-Pesa/Daraja, PayPal, Stripe, PayStack, cards, bank transfers and the POS feed the same ledger as first-class adapters, because every collection belongs to the same books.
• Orders from the front — e-commerce and sales tools push orders into the ERP, so selling online and selling over the counter are one inventory, one ledger.
• Statement imports — bank statements load and match automatically, turning reconciliation from a typing exercise into a verification exercise.
• CRM and ERP handshake — the customer file is joined to the customer account, so the sales story and the money story share one party.
• Webhooks with dead-letter honesty — integrations retry idempotently and quarantine what fails, so a lost order or a lost payment never silently disappears.
• Exports for every stakeholder — the accountant, the analyst and the statutory reviewer each get the shape they need, from the same source.

An ERP is the hub of the company's information, and hubs exist to be connected. We wire the network so the books stay one truth in a many-system world.

19

Migrations into one record

Every ERP project inherits a mess — spreadsheets full of stock, invoices in an inbox, suppliers in an address book. The migration is where the project lives or dies. We treat it as a verification exercise: clean the data, move the history, prove the totals, and keep the business trading the whole time.

• Inventory counted before it is loaded — physical stock and the opening balances move together, so the system's starting truth is a verified one.
• Suppliers with their history — supplier files carry their terms, outstanding balances and contact trail, so payables inherit reality instead of starting from zero.
• Customer accounts carried — aged receivables move with their invoices and payment history, so the balance is a sum of real documents, not a typed total.
• Historical figures intact — past periods keep their dates and totals, so comparative reporting is possible from day one instead of 'since go-live'.
• Verification at every batch — row counts, KES totals and ageing distributions are compared after each import, so a bad batch is caught before it is relied upon.
• A reversible path — the migration rolls back cleanly if the new environment misbehaves, so the business keeps trading on the old records while we fix.

A good migration is one nobody notices afterwards — the old spreadsheets disappear because the new record already contains their truth, verified.

20

Security: who touches what, and what changes are recorded

An ERP holds the company's full commercial truth — costs, margins, cash, payroll, stock. Access must follow role and function, changes must be audited, and the person who can change a number must not be the person who can hide the change. The same discipline that protects our payment ledger protects your books.

• Roles mapped to function — the cashier sees cash, the buyer sees procurement, the accountant sees the ledger, the owner sees the whole; access follows the job.
• Row-level data control — branch and department scope the records the database serves, so nobody sees what their operation does not need.
• Approvals bound to authority — a user's approval power matches their recorded limit; the system refuses to route a decision past its owner's capability.
• Audited changes everywhere — every edit to a master record, every approval, every posting carries actor and timestamp, and nothing overwrites silently.
• Segregated duty on the money — the person who records a payment is not the person who approves it, enforced by the workflow, not by roster.
• Session and device control — sign-in discipline, session limits and revocation mean access ends when employment ends, not when accounts get remembered to be closed.

In an ERP, security is mostly quiet competence — the right eyes on the right numbers and a trail for everything changed. Silence in the audit log is the sign it is working.

21

Operations: the nightly close and running the system

An ERP is judged by the close — nightly, weekly, monthly — and by the ordinary Tuesday when the floor just uses it. We build the operational layer: scheduled jobs with advisory locks, monitored health, rehearsed backups, documented runbooks and a support path with timelines, so the system runs its own discipline and reports honestly when it cannot.

• The nightly close — reconciliation, aged balances, stock movements and posting integrity checks run on clocks, with advisory locks so overlapping runs cannot double anything.
• Month-end that assembles itself — closing entries, accrual checks and report packages prepare in sequence, so 'close the books' is a supervised flow rather than a marathon.
• Health monitoring — integration latency, queue depth, error rates and long queries are watched before users notice, because slow is a papercut with a timeline.
• Backups that restore — restores are rehearsed, not assumed; a backup that has never been restored is a hope, not a backup.
• Documented runbooks — the business can run its own system: who to call, what to check, how to close the month, how to get help.
• Honest degradation — when things are slow or partial, they are reported as such; a signal that degrades gracefully beats radio silence that panics.

The ERPs that last are the ones somebody keeps healthy on an ordinary morning. We build the operations so ordinary mornings stay ordinary.

22

Honest limits of an ERP

An ERP is a powerful discipline and a demanding one. It will not fix a business model, it will not make people enter data honestly, and it cannot reconcile what was never recorded. Saying these limits plainly is part of the service — the vendor who implies the software runs the company is selling the next failure.

• An ERP is a discipline, not a machine — the books are only as honest as the recording habits around them; we build guard rails, but the floors must feed the records.
• Data quality is a standing cost — masters must be maintained, counts must be taken, variances must be explained; that cost is part of running the business well.
• It will surface, not fix, broken process — if the buying habit is chaotic, the ERP will make the chaos visible and auditable, not pleasant.
• The close is a habit, not an event — reconciliation, verification and review must be kept current; the system supports the habit but does not replace it.
• Money software is never finished — rails, regulation and fraud evolve; running an ERP with money inside is a standing duty, not a one-time build.
• You own it all — the code, the data, the charts of accounts and the keys are the client's; nothing that runs the company's books should be hostage to a vendor.

We would rather tell you the honest cost of the discipline than sell you a system you inherit without owning. And when the limits are accepted, the system built inside them genuinely holds.

The toolchain

The operations backbone toolchain

The stack we bring to an ERP is the machinery of a live money platform applied to the whole operation — ledgers that balance, inventory that is true, procurement that is approved, and reporting that survives being checked against the floor and the bank.

Lifecycle

The ERP lifecycle — from scattered records to one set of books

Every ERP we build follows the same arc: understand the real flows, model the books, wire procurement and inventory, connect the money, prove it against the bank, and then keep the discipline alive through the close, the audit and the growth.

Closing

More than development

An ERP is the business's nervous system — the one set of connected records from which every decision, every payment and every report is drawn. We build it so the books actually balance. That includes:

An ERP is not a project you finish; it is a state a business commits to — one set of records, one set of rules, one view of the truth, kept honest by the daily close and the monthly audit.

We run this discipline every day on KodiiPay's own ledger. When your business needs it, you get the machinery that survived being live — not the one that survived only a slide.