Business Systems

Custom ERP development shaped by how you actually operate

An ERP is the system your finance team, your warehouse and your production floor all have to agree with. We build that agreement into software instead of into a fortnightly reconciliation meeting.

What is ERP development?

ERP Development is the design and build of an enterprise resource planning system covering finance, inventory, purchasing, production and reporting in one place. It suits Australian organisations running several entities, warehouses or trading names on a patchwork of spreadsheets and disconnected tools, where reconciliation is manual and nobody quite trusts the numbers.

Get a fixed written quote
Typical timeline
20 to 40 weeks
What drives cost
The number of modules you genuinely need, how many legal entities and sites roll up together, and the state of the data being migrated.
Best for
Multi entity or multi-warehouse operations that have outgrown spreadsheets and add ons
You own
The source code, the database and every environment it runs in
Built with
Modular services, role-based access, immutable audit logging, MYOB and Xero connectors
What the system containsGeneral ledgerAccounts payablePurchasingInventoryProduction runsJob costingPayroll exportsBoard reporting
One record of truth replaces the spreadsheets sitting between finance and the floor.

Your handover

What a custom ERP actually replaces

Almost nobody comes to us starting from nothing. They arrive with a stack that grew one problem at a time: accounting in MYOB or Xero, stock in a spreadsheet one person maintains, purchase orders in a shared inbox, job costing in a second spreadsheet that never quite reconciles with the first, and a production schedule on a whiteboard someone photographs each morning. Every piece works. The gaps between the pieces are where the margin leaks.

  1. 01Documented process maps of your current operation
  2. 02Data quality report and cleansed migration set
  3. 03Core ERP modules for finance, stock, purchasing and costing
  4. 04Role-based access model with approval thresholds and delegation
  5. 05Append only audit trail with configurable retention
  6. 06MYOB or Xero integration reconciled against a closed month
  • Operational reporting and exportable dashboards
  • Administrator and end user training recordings
  • Source code, database and deployment pipeline in your name
An ERP closes the gaps rather than replacing the pieces for the sake of it

An ERP closes the gaps rather than replacing the pieces for the sake of it. Raise a purchase order and it reserves stock, commits spend against a cost centre and appears in the supplier's expected receipts. Receive the goods and the receipt updates stock, matches the order and the invoice, and flags the variance when the three disagree. Nobody rekeys anything, and the figure on the board report is the same figure the warehouse supervisor is looking at. That single source of truth is the whole commercial case.

  • One stock figure that finance, sales and the warehouse all read from
  • Purchase to pay with three way matching instead of manual checking
  • Job and product costing calculated from real transactions, not estimates
  • Intercompany transactions handled between entities without journals by hand
  • Reporting that does not require anyone to export to Excel first

An ERP closes the gaps rather than replacing the pieces for the sake of it.

Getting fifteen years of spreadsheets into one database

Data migration is underestimated in every scoping conversation we have ever had. Moving rows is trivial. The hard part is that your spreadsheets encode decisions nobody wrote down: three spellings of the same supplier, part numbers that changed convention in 2019, a column called Notes that holds delivery instructions, credit terms and one person's reminder to chase a warranty claim.

More on getting fifteen years of spreadsheets into one database

So we treat migration as a data quality project with a deadline attached. We profile what you have and report duplicates, gaps and contradictions with counts rather than adjectives. Your team then makes the calls only they can make, such as which of four customer records is the real one. We write the transformation rules, run a full trial migration into a test environment, and reconcile totals against your current reports line by line. A trial balance and a stock valuation that match to the cent are the gate we insist on before go live, because a system that is 97 percent right is a system nobody uses.

How the engagement runs

How a custom ERP rollout is staged

We do not attempt a single overnight cutover of an entire operation. Big bang ERP launches are how organisations end up unable to invoice for a fortnight. Instead the build is sequenced so each stage delivers something usable, runs alongside the existing process for a period, and is only relied on once it has proven itself against the old numbers.

  1. 01Process mappingSit with the people doing the work and record how it is really done, including the workarounds
  2. 02Data profilingAssess what your spreadsheets and current systems actually contain, with a written quality report
  3. 03Core modelEntities, sites, cost centres, product and supplier structures agreed before any interface is built
  4. 04First module liveUsually purchasing or inventory, run in parallel with the existing process for a full cycle
  5. 05Finance integrationConnectors to MYOB or Xero, reconciled against a closed month before being trusted
  6. 06Remaining modulesProduction, job costing and reporting added in agreed order, each with its own acceptance test
  7. 07HandoverAdministrator training, documented runbooks, and a support period through your first end of financial year
DiscoverDesignBuildTestHandover
Two decisions on your side that keep the project moving

The sequence below usually spans two to three quarters for a mid sized operation. It slows down for one reason far more than any other, which is availability of your people. The warehouse supervisor who knows why the receipting process has that odd extra step is the most valuable person in the project, and we need a few hours of their time each week. We agree that commitment before starting rather than discovering it in month four.

Choose the right level

Does an ERP replace MYOB or Xero?

Usually not, and we push back when a client assumes it must. Your accounting package is doing a job it does well: statutory reporting, BAS and GST treatment, payroll in many cases, and a chart of accounts your accountant already understands. Ripping that out to rebuild general ledger functionality inside a custom system is expensive and rarely improves anything.

Function

01

Stock, batches and serials

Lives in the ERP

Yes, with movement history

Stays in MYOB or Xero

No, a summarised valuation only

02

Purchase orders and receipting

Lives in the ERP

Yes, with approval chains

Stays in MYOB or Xero

Receives the matched supplier invoice

03

Job and production costing

Lives in the ERP

Yes, from real labour and material transactions

Stays in MYOB or Xero

Receives the cost of sales journal

04

General ledger, BAS and GST

Lives in the ERP

No

Stays in MYOB or Xero

Yes, it remains the statutory record

05

Payroll

Lives in the ERP

Feeds hours through only if you use timesheets

Stays in MYOB or Xero

Yes, with Single Touch Payroll reporting

How we work this out during scoping

The far more common shape is an operational ERP that owns stock, purchasing, production and job costing, posting summarised journals into the accounting package on a schedule. The design question is which system owns each fact. We answer that explicitly, in writing, before a connector is written, because ambiguity there is what makes integrations fail quietly six months later. The table below is the split we recommend most often for Australian small and mid sized operations.

Role-based access, approval chains and the audit trail

In a business of any size, who may do what is a control, not a convenience. We model roles against real jobs rather than job titles: a store person can receive against an order but not create one, a purchasing officer can raise orders up to an agreed limit, anything above it routes to a manager, and anything above a second limit routes to a director. Approval chains carry delegation rules so a purchase order does not sit unactioned for a fortnight because one person is on leave, and segregation of duties is enforced by the system rather than by everyone remembering the policy.

Retention periods are configurable, because the right answer differs by record type

Underneath sits an audit trail that records every change, who made it, when, and the values before and after. It is append only, so records can be corrected but not quietly rewritten. This matters more than it sounds. It is what lets your accountant answer a question from the ATO without a forensic exercise, what your insurer or a tier one customer expects to see during a supplier audit, and what satisfies the Privacy Act 1988 obligations around access to personal information you hold. Retention periods are configurable, because the right answer differs by record type.

When a custom ERP is the wrong call

If you are a single entity turning over a few million dollars with one warehouse and a catalogue in the hundreds, a custom ERP is almost certainly over engineering. Xero or MYOB plus a well chosen inventory add on will do the job for a fraction of the effort, and you will get it working this quarter rather than next year. We would rather tell you that on the first call than take the project.

The rest of the answer

There is also a middle option people forget. A great many businesses that think they need an ERP actually need three or four specific problems solved: stock accuracy, quoting, and getting job data out of a spreadsheet. That can look like a dedicated inventory system, a purpose built CRM or a set of automated workflows joining tools you already pay for. Custom ERP earns its cost when the complexity is genuinely structural: multiple entities, real manufacturing, or operations across states that must roll up into one set of numbers. We see that most often in manufacturing and in distribution, and we will say plainly which side of the line you sit on.

How we scope it

Four ways to scope your ERP Development project

We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.

ERP Pilot

One team, one process, proven before you commit further

Fixed written quote, agreed before work starts

  • Documented process maps of your current operation
  • Data quality report and cleansed migration set
  • Core ERP modules for finance, stock, purchasing and costing
Request a quote
Most common

ERP Rollout

The whole department, integrated with what you already run

Fixed written quote, agreed before work starts

  • Everything in ERP Pilot
  • Role-based access model with approval thresholds and delegation
  • Append only audit trail with configurable retention
  • MYOB or Xero integration reconciled against a closed month
Request a quote

ERP Enterprise

Multi site or multi entity, with the governance that needs

Fixed written quote, agreed before work starts

  • Everything in ERP Rollout
  • Operational reporting and exportable dashboards
  • Administrator and end user training recordings
  • Source code, database and deployment pipeline in your name
Request a quote

ERP Support

Changes, training and support as the business shifts

Rolling monthly, quoted in writing

  • Changes and new requirements as the business shifts
  • Training for new staff, recorded so it is reusable
  • Patching, backups and a restore that has been tested
  • Rolling, cancel with 30 days notice
Request a quote

These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.

Questions buyers usually ask

Frequently asked questions

How long does a custom ERP take to build and roll out?

Plan for 20 to 40 weeks from kickoff to the last module going live. The first usable module typically lands within the first third of that, because we sequence the rollout rather than launching everything at once. The variables that move the date most are the state of your existing data and how much time your operational staff can give to process mapping and acceptance testing.

What drives the cost of an ERP project?

Four things account for most of the variation: the number of modules you genuinely need, how many legal entities and sites must roll up together, the condition of the data being migrated, and how many external systems have to connect. We scope those in a discovery phase and issue a fixed written quote against a defined scope, so the figure only moves if you change what is being built.

Do we own the system if we stop working with you?

Yes, completely. The repository sits under your organisation, the database is yours, the cloud accounts are registered to your ABN with your billing details, and We are added as a collaborator, never as the owner, and you can remove us. Documentation is written for a developer who has never met us. There is no licence fee to us and no proprietary layer holding the system together.

Can staff use it on a factory floor or a site with poor reception?

Yes, and we design for it where it matters. Scanning, receipting and job entry screens can be built to queue transactions locally and sync when a connection returns, with conflict rules agreed up front so two people counting the same bin does not create a mess. We test this deliberately on real devices in real conditions rather than assuming warehouse wifi is reliable.

What happens at the end of the financial year?

We plan the rollout so that a full end of financial year runs while we are still engaged. That means your first year end close, stocktake and BAS periods happen with us on hand, and any reporting gaps are found and fixed while it is still our problem. After that most clients keep a modest support arrangement for enhancements and for the reporting requests that always follow a first full year.

How does an ERP handle multiple companies or trading names?

Entities are modelled from the beginning rather than bolted on, because retrofitting multi entity support is expensive. Each company keeps its own ledger, tax settings and document numbering, users are scoped to the entities they work in, and intercompany transfers create matching records on both sides automatically. Consolidated reporting then rolls up without anyone maintaining a spreadsheet to combine the results.

Get a fixed written quote for your ERP

Tell us how many entities, sites and systems are involved, and what your team currently reconciles by hand. We reply within one business day.