ERP
ERP development for the operations a suite never quite covered
We build ERP-style systems where a full suite is too heavy or too wrong: procurement, inventory, job costing, and the approvals around them. Finance remains the system of record unless there is a clear reason to move it.
- Procurement
- Inventory movements
- Job or project costing
- Approval chains
Start from a module, not a slogan
“We need an ERP” often means purchase orders are in email, stock is in a sheet, and month-end is a reconstruction. The first release should close one of those gaps and post cleanly to whatever ledger you already trust.
Controls are the product
Separating who requests, who approves, and who receives is not a setting to turn on later. Neither is an audit trail, a period close, or a reason code when someone overrides a price. Those are designed with the screens.
One module that a department uses
The first module
- The document that starts the work
- The approval that must be recorded
- Stock or cost that this module is allowed to change
A programme, not a release
- Every department on one go-live day
- A replacement for the finance system of record
- Shop-floor hardware with no protocol list
What changes an ERP slice
Source of truth
Say which system owns money, stock, and the customer. The new module should post to it.
Approvals
Who can approve, and what evidence they need, is the product. Screens come after that.
Migration
Opening balances and open orders decide the date more often than the screens do.
What an ERP slice needs named
- 01
The document
The request, order, or transfer people argue about.
- 02
The approver
Who may say yes, and what they need to see.
- 03
The ledger
Which system owns money. This module should post to it.
- 04
Open items
Balances and orders that must exist on day one.
Marks an ERP slice is trustworthy
- 01
One status
The request, order, or transfer has a single current state people agree on.
- 02
Approval is recorded
Who said yes, and what they saw, stays on the document.
- 03
Money posts
The module writes to the ledger that already owns the accounts.
- 04
Day one balances
Open orders and balances exist before anyone is asked to stop using the sheet.
What we build
Procurement
Requests, orders, receipts, and a match against what was approved.
Inventory movements
Locations, adjustments, and a history that explains a variance.
Job or project costing
Costs collected against the work you sell, not only against a general ledger code.
Approval chains
Limits by amount, branch, and role, with a record of the decision.
How an engagement runs
- 01
Pick the ledger boundary
What stays in the existing finance system, and what this product must post back.
- 02
Document the control points
Approvals, overrides, and the reports management already asks for.
- 03
Pilot one department
Run a full cycle before every warehouse is on the new screens.
Questions we hear
Will you replace SAP, Oracle, or Dynamics?
Rarely as a big-bang replacement. We more often build the operational layer those systems do not fit, or integrate so people stop re-keying.
Can a trading company use this?
Yes. The trading and investment industry page covers shipments, positions, and counterparties. The ERP solution page covers the module shape.
How do you treat VAT and invoicing?
Tax treatment is confirmed with your finance adviser. We implement the document flow and the fields they specify. We do not give tax advice.