Custom Manufacturing ERP Problems: The 7 That Cost Job Shops Real Money, and How to Avoid Them

Why does the build turn into a general ledger replacement?

Nobody proposes rebuilding accounting on day one. It arrives in pieces. Job costs need to reach the ledger, so a posting mechanism appears. Purchase orders for outside processing need approval, so a purchasing module appears. Then invoicing, then receivables ageing, and a year later you own a general ledger that is worse than the one you already licensed and a routing engine that never got finished.

This is specific to manufacturing because the accounting boundary genuinely is blurry. A job is simultaneously an operational object and a cost object, and it is not obvious where one system should stop. In most other categories the boundary draws itself.

Draw it deliberately and write it down. The custom system owns routing, work centres, shop floor data collection, job costing, scheduling, quoting and traceability. Accounting stays in QuickBooks or Sage, and the interface between them is a defined set of postings agreed with your controller before code. Anything proposed outside that list goes on a separate page for the phase after the first release ships.

The reason this matters more than it sounds: your shop is different from the shop down the road in exactly one place, which is how work moves through it and what that work costs. That is where the money belongs. Nothing about your accounts payable is a competitive advantage, and every week spent on it is a week the dispatch list stays wrong.

What goes wrong when E2 or JobBOSS job history comes across?

The data extracts cleanly. That is not the problem. The problem is what the data means.

Historical job records in an incumbent system were produced under the constraints that made you want to leave. Labour hours were batched in from memory at shift end, so operation-level times are approximations with a systematic bias toward round numbers and toward the end of a shift. Rework was recorded as a second job with cost journalled across, so the original job looks profitable and the rework job looks catastrophic and neither reflects the part. Burden was a single plant-wide rate, so the machining hours and the deburr hours carry the same overhead. And a proportion of jobs were closed with a manual adjustment to make the numbers land.

The failure mode is loading all of that into a new quoting engine that surfaces the three most similar historical parts and shows quoted against actual hours. The feature is excellent. The data underneath it teaches your estimators the wrong lesson, confidently, and nobody questions it because it is now on a screen rather than in a spreadsheet.

Migrate with labels. Bring history across, keep E2 or JobBOSS running read-only for a year so old quotes and closed jobs stay searchable, and mark historical records as pre-system so any comparison shows which side of the line it came from. Then let the new system build its own history, and expect the quoting feedback loop to become genuinely trustworthy after a few quarters of clean data rather than on day one. Say that out loud at kickoff, because a shop expecting instant quoting intelligence will be disappointed at exactly the moment adoption is fragile.

Why do the accounting, machine monitoring and customer integrations break after launch?

Three connections matter in a job shop and each fails in its own way.

Accounting sync breaks on mapping and on period close. A new work centre, a new cost type or an outside process account that was not mapped posts to a default, or fails, and your controller finds it at month end. Postings that land against a closed period are the other common one. Both fail quietly because the shop floor sees nothing.

Machine monitoring breaks on interpretation rather than connectivity. A machine reports spindle time, which is not the same as the operation time you are costing, and it certainly is not setup. When the feed drops out or a machine is swapped, the run rates it was feeding become stale and nobody notices because the numbers still look plausible.

Customer electronic data interchange breaks on their schedule. Aerospace and automotive customers test when their team has capacity, and a release date that assumes two connections land together will slip on the one you promised.

The controls are the same shape in each case. Unmapped items go to a visible queue with a dollar value and an owner rather than to a default account. Feeds are monitored for plausibility, not just for uptime, so a stale machine feed raises rather than quietly flattening your production rates. And each customer connection is sequenced separately with their testing window in your project plan.

What happens when traceability and access control are not designed in week one?

Compliance in this category is a data architecture decision, not a module, and that is the whole point.

The AS9100 case is concrete. An auditor asks for full genealogy on a shipped lot: the heat number, every operation, every operator, and every outside process certificate. If certificates are file attachments hanging off a job, assembling that answer is four days of digging through attachments, email and paper. If lot genealogy is the data spine, with heat lot to raw stock to every split, merge, rework loop and shipment, and certificates attached to the exact routing step that produced them, the audit package is an export. The difference between those two outcomes was decided in week one of the build and cannot be retrofitted cheaply, because retrofitting means re-deriving genealogy for records that never captured it.

The ITAR case is sharper. If controlled prints sit on a network share open to the whole company, no amount of application-level permission fixes it, and a custom build that stores documents alongside jobs without part and document level access control has moved the problem rather than solved it. Access has to be enforced by the system, with a log, rather than by hoping.

Ask any prospective developer to walk you through an audit export and an access model from prior work. If those are not immediate, confident answers with a real example behind them, they will build the module in month nine and you will discover the schema does not support it.

Should you build custom or configure what you already own?

A real share of shops reading this should not build, and it is worth being direct.

Under roughly $5 million in revenue, single plant, mostly repeat work with genuinely linear routers, and a complaint that is about reporting rather than modelling: stay. JobBOSS or E2 is cheaper and faster than anything custom at that profile, and newer shop systems such as ProShop and Fulcrum are worth a trial before spending a dollar on development. Upgrade rather than build if your pain is screens, speed or reporting, because those improve between versions.

It is also worth asking whether what you own has been configured. Many shops run an incumbent system on defaults set during an implementation nobody currently employed remembers, with one plant-wide burden rate and a data collection flow that was never simplified. Fixing the burden rate structure alone changes your margin reporting materially and costs nothing.

The signal to build is never a missing feature. It is the data model. When rework loops and split lots force you to create fake jobs and hand-move cost, when a second location turns every transfer into double entry, when the real schedule is rebuilt in Excel every morning from a walk of the floor, no amount of configuration repairs that, because the wrong assumptions are in the schema. If you have two of those and a six figure budget, build a focused system for those two problems and leave accounting alone.

How do hidden costs get into the quote?

Five items are routinely absent from estimates in this category.

Work centre count and machine monitoring. Each integration is real work and each is ongoing maintenance, and a quote that says machine integration without naming controls and protocols has not been costed.

Finite scheduling depth. Scheduling against an operator skills matrix, fixture availability and real outside process lead times by vendor is a different project from a capacity calendar, and the two get quoted with the same words.

Compliance regimes. AS9100 documentation and ITAR data segregation are architecture from week one, and pricing them as a later module is the tell that they will be bolted on badly.

Migration and parallel running. Extracting E2 or JobBOSS history is a defined workstream, and running parallel for one or two order cycles is real time from your schedulers and controller, not from developers.

And the plants. Launching two at once rather than sequencing them is not twice the work, it is more, because you are debugging a new system and reconciling two sets of practice simultaneously. Add 15 to 20 per cent of build cost annually for hosting, support and steady improvement once live.

What separates a build that works from one that fails here?

Four things, and the first decides adoption before anything else does.

Clocking onto an operation has to take under ten seconds at the machine, via a scanner or a mounted tablet. This is not a nicety. Every number the system produces comes from floor transactions, and if the flow is slow or requires walking to a shared terminal across the aisle, operators will batch entries from memory at shift end and your costing is guesswork with better formatting. Time the flow in a demo. If the floor interface needs a training manual, it was designed wrong.

Second, the routing model is a directed graph rather than a numbered list, decided in the first design session. A failed inspection spawns a rework path with its own operations and costs rolling back into the parent job, lot splits carry genealogy, and outside operations are routing steps with a linked purchase order and expected turn days. If a developer offers to add a status field, the interview is over.

Third, burden lives at the work centre. A single plant-wide rate means your five axis machining centre subsidises the manual deburr bench in every margin report you produce, and you will keep quoting your worst work at your best margin because the reports cannot tell you otherwise.

Fourth, phase rather than replace. Take the two problems doing the most damage, usually job costing and the daily schedule, ship those in 12 to 16 weeks, run parallel for an order cycle or two, then expand. Big bang replacements in this category fail far more often than phased builds, and the spreadsheets you keep in the meantime are doing useful work.