§ 03Custom ERP
ERP software development services
An ERP is one set of records that finance, purchasing, stock, sales and operations all work from. We design and build custom ERP software around how your company actually trades, module by module, and connect it to the tools you keep.
| Time | Event | Module | Effect |
|---|---|---|---|
| 10:02 | Order confirmed | Sales | credit check passed · 3 lines |
| 10:02 | Stock reserved | Inventory | WH-1 · 3 lines reserved |
| 14:30 | Picked and shipped | Warehouse | shipment SH-2209 |
| 14:31 | Invoice issued | Finance | INV-30871 · $18,240.00 |
| 14:31 | Posted to ledger | Ledger | revenue · COGS · receivable |
| - | Payment received | Finance | due in 30 days |
What this page covers
- 01Shared master data
- 02Modules
- 03Postings
- 04Roles
- 05Integrations
- 06Migration
- 07Phased rollout
§ 01Definition
A custom ERP is one data model with modules on top
ERP development is often described as building one big system. In practice it means building one shared data model (customers, suppliers, items, locations, accounts) and the modules that read and write it. When the sales order, the stock reservation and the ledger posting are the same transaction, month-end reconciliation stops being a project.
- 1shared data model
- 7modules to choose from
- 1module to start with
§ 02Modules
Modules we build
Our ERP software development services scope each module separately and build it on the same records. Most companies start with two or three modules, not all seven.
Finance and ledger
The general ledger and the subledgers that feed it. Postings come from operational events, so every figure can be traced back to the document that created it.
- General ledger and chart of accounts
- Accounts receivable and payable
- Multi-entity and multi-currency postings
- Period close checklist and locks
- Cost centres and project codes
Purchasing and suppliers
From purchase request to supplier invoice, with approval limits and three-way matching against goods received.
- Purchase requests and approvals
- Purchase orders and supplier confirmations
- Goods receipt against PO
- Three-way match: PO · receipt · invoice
- Supplier price lists and lead times
Inventory and warehouses
Stock as a ledger of movements across warehouses and locations, valued consistently with finance.
- Locations, bins, lots and serials
- Receipts, transfers, picks and adjustments
- Cycle counts with approval of variances
- Reorder points and replenishment proposals
- Stock valuation feeding the ledger
Sales and order management
Quotes, orders, allocation, shipping and invoicing as one lifecycle with credit and pricing rules.
- Quotes and order entry
- Price lists, discounts and customer terms
- Credit limits and order holds
- Partial shipments and back orders
- Returns and credit notes
Production
Bills of materials, work orders and material consumption, connected to stock and costing.
- Bills of materials and routings
- Work orders and material issue
- Output and scrap reporting
- Work-in-progress valuation
- Capacity view by work centre
Projects, jobs and time
For companies that sell projects or services: budgets, time, costs and billing against milestones.
- Project budgets and phases
- Timesheets with approval
- Costs and purchases charged to projects
- Milestone and time-and-materials billing
- Project margin reporting
Operational and financial reporting
Reports built from the same records the modules use, so operations and finance see the same numbers.
- Role dashboards and work queues
- Margin by customer, product and project
- Stock ageing and turnover
- Scheduled exports for BI tools
- Audit trail across modules
§ 03Order to cash
One transaction, every module
The value of an ERP shows in a single order. Each step below happens in a different module and is owned by a different team, but it is one record moving through one system. Nobody re-keys it, and every posting links back to the order.
- Quote: done
- Order: donecredit + price rules
- Reserve: doneby warehouse
- Ship: done
- Invoice: donefrom shipment
- Post: in progressautomatic
- Collect: not startedbank match
§ 04Decision
Build, configure or extend
An ERP software development company should be clear about where custom work is the wrong answer. This is ours.
| Question | Packaged ERP, configured | Packaged ERP + custom modules | Custom ERP |
|---|---|---|---|
| Fits when | Your processes match the industry template. | Most processes fit; one or two do not. | Your core process is how you compete, or no package covers it. |
| Licence model | Per user, per module. | Per user, plus custom code upkeep. | No per-user fees; you pay for build, hosting and change. |
| Change speed | Vendor release cycle. | Upgrades can break extensions. | You decide what changes and when. |
| Data model | The vendor’s. | The vendor’s, extended. | Yours, designed around your records. |
| Who we are for | Not us: choose an implementation partner for that product. | We can build the custom modules and integrations around it. | Our core ERP work. |
§ 05Access
Roles across modules
In an ERP, access control is also financial control. Who can adjust stock, post a journal or close a period is decided with your controller and enforced on every screen, import and API call.
| Role | Create orders | Approve POs | Adjust stock | Post journals | Close period | See margins |
|---|---|---|---|---|---|---|
| Sales | Yes | No | No | No | No | Own only |
| Buyer | No | Approves ≤ $20,000 | No | No | No | No |
| Warehouse lead | No | No | Approves Approves | No | No | No |
| Accountant | No | No | No | Yes | No | Yes |
| Controller | No | Approves > $20,000 | Approves Approves | Yes | Yes | Yes |
§ 06Integrations
What the ERP exchanges with
A custom ERP does not have to do everything. Payroll, tax filing and BI often stay in specialist tools, and the ERP exchanges data with them on a defined schedule.
| Connected system | Direction | What moves | When |
|---|---|---|---|
| Bank | Custom ERP ↔ Bank | payments · statements | daily file |
| E-invoicing / tax | Custom ERP → E-invoicing / tax | invoices | on issue |
| Online store | Online store → Custom ERP | orders · customers | webhook |
| CRM | Custom ERP ↔ CRM | accounts · quotes | on change |
| Payroll provider | Payroll provider → Custom ERP | payroll journals | monthly |
| BI tool | Custom ERP → BI tool | reporting tables | nightly |
§ 07Migration
Migration and phased rollout
ERP projects fail when everything goes live at once. Ours go live module by module, with opening balances reconciled and signed off by finance before each switch.
- 01phase
Master data first
Customers, suppliers, items, locations and the chart of accounts are cleaned, deduplicated and loaded. Everything else depends on them.
- Handed over
- Master data load with a sign-off report
- 02phase
First module live
Usually the module causing the most pain, often purchasing or inventory. It goes live with integrations to the systems that stay.
- Handed over
- Working module and integration logs
- 03phase
Opening balances
Open orders, stock on hand and open receivables and payables are migrated at a cut-off date and reconciled line by line.
- Handed over
- Reconciliation report signed by finance
- 04phase
Parallel period
Where the risk justifies it, the old and new systems run side by side for a period and the results are compared before the old one is switched off.
- Handed over
- Comparison report and cutover decision
- 05phase
Next modules
Further modules join one at a time, each reusing the shared records instead of creating its own copy.
- Handed over
- Release notes and role guides per module
Example scope of a first release
- 5modules
- 7roles
- 4integrations
- 2migration sources
Ideal when
- Finance, stock and operations keep separate records that disagree every month
- A packaged ERP was evaluated and would force core processes into its template
- Spreadsheets and a patchwork of tools have become the de facto ERP
You receive
- Shared data model and module specifications
- Modules in production, with role-based access and audit
- Integration specifications and logs
- Migration reconciliations, source code and runbooks
Not in scope
- Implementing or configuring a vendor ERP product on its own platform
- Statutory payroll calculation (integrated from a payroll provider instead)
- Hardware such as scanners or terminals (we integrate with them)
§ 08Questions
Questions about custom ERP
What is ERP software development?
It is the design and build of an enterprise resource planning system: a shared data model for customers, suppliers, items and accounts, plus modules (finance, purchasing, inventory, sales, production) that work on those shared records. Custom ERP development builds that system around a company’s own processes instead of configuring a packaged product.
How do I make my own ERP system?
Start from the data, not the screens. Define the master records and the transactions that change them, decide which module causes the most pain today, and build that one first with integrations to the systems you keep. Add modules one at a time on the same data model. Trying to build every module before anyone uses one is the most common reason ERP projects fail.
Should we build a custom ERP or implement a packaged one?
If your processes are standard for your industry, a packaged ERP configured by a specialist partner is usually the better choice. Custom ERP makes sense when a core process is specific to how you operate, when licence costs per user dominate, or when you only need some modules and must integrate them tightly with existing tools.
What is replacing traditional ERP?
Many companies now combine a smaller core (finance and shared master data) with specialised systems around it, connected by integrations instead of one monolithic suite. A custom ERP can be built the same way: a shared core with modules that can be replaced independently.
What drives the cost of a custom ERP?
The number of modules, the number of distinct transactions and approval rules, the number of integrations, the amount and quality of data to migrate, and whether a parallel run is needed. Phased delivery lets you fund one module at a time against a known scope.
How do you avoid losing data during the switch?
Master data and opening balances are migrated in trial loads first, each reconciled against the source by count and by value. Finance signs off the reconciliation before cutover, and the old system stays available read-only for lookups.
Next step
Start with the module that hurts most.
Tell us which records disagree between teams today, and which systems you want to keep. We will propose a first module and the shared data it needs.
brief.txt · what helps us most
- 01The tools that act as your ERP today
- 02Which records disagree between teams
- 03Entities, currencies and warehouses involved
- 04What must stay in its current system