Shop floor (MES)
- ERP sends released work orders and bills of materials
- MES returns actual quantities, consumption and scrap
- Interface shaped on the ISA-95 level 3 to level 4 boundary
- No direct writes from machines into ERP tables
Custom ERP Development
Custom ERP development services
Your packaged ERP fits the standard order and invoice, but not the way you plan production, price contracts or move stock, so the real work runs in spreadsheets. Agnotic Technologies builds the ERP modules your process needs, beside or instead of a packaged system, and connects them to the shop floor, the warehouse and your trading partners.
Build or extendModules in orderMES, WMS and CRM linksEDI with partners
Trusted by global innovators
What is custom ERP development?
Custom ERP development is building or extending the enterprise resource planning software that runs orders, inventory, purchasing, production and finance postings, so it follows how your business actually works. Agnotic Technologies builds custom ERP modules, extensions and integrations for companies whose processes do not fit a packaged ERP's standard setup.
It rarely means rewriting everything. A packaged system can often keep the general ledger, payroll and tax, while the custom build covers the parts where your process is the reason you win business.
Testing an ERP through vendor updates is covered on our ERP testing page. This page is about deciding what to build, in what order, and how it connects.
Decision table
Should you configure, extend or build your ERP?
Four routes, from least to most code you own. Pick the first row that removes the spreadsheets.
| Route | Choose it when | What you own and maintain | Main risk | Effect on vendor upgrades |
|---|---|---|---|---|
| Configure a packaged ERP as shipped | Your processes match the vendor's standard flows, or you are willing to change them to match | Configuration, master data and reports | Work that does not fit moves back into spreadsheets | Lowest: upgrades follow the vendor's schedule |
| Extend a packaged ERP | The core fits, but a few processes such as pricing, quoting or approvals need custom logic | Extensions built on the vendor's supported extension points and APIs | Extensions written against internal tables break on upgrade | Medium: each update needs regression testing of the extensions |
| Build custom modules beside a packaged core | Finance and payroll fit a packaged system, but operations such as production planning or field service do not | The custom modules and the integration that posts into the packaged ledger | Two systems disagree about the same record if ownership is not agreed | Medium: the integration contract has to survive both release cycles |
| Build a full custom ERP | The business model has no packaged equivalent, or licence and change constraints rule packaged systems out | Everything, including finance postings, audit trail and reporting | Rebuilding commodity accounting that adds no advantage | None from a vendor, but every regulatory and tax change becomes your team's work |
We recommend the least custom route that removes the spreadsheets. If configuration alone does it, we say so on the scoping call.
Build order
Which ERP modules should you build first?
Start with the records every other module depends on, then the module that is the reason for building at all.
Item master and units of measure
Products, variants, units and conversions, lot and serial rules. Every later module reads these, so mistakes here spread everywhere.
Customers, suppliers and locations
Parties, sites, warehouses and bins, with the identifiers your partners already use so EDI and CRM data can be matched.
Inventory and stock movements
Receipts, transfers, adjustments and the valuation method finance has agreed, with every movement traceable to a document.
The module that differs
Production planning, contract pricing, rental, field service or whatever process is the reason you are building. This is the first release your users will notice.
Order to cash and procure to pay
Sales orders, shipments and invoices, then purchase orders, receipts and supplier invoices, built around the modules above.
Ledger postings and reporting
Journal postings to your general ledger, whether that ledger is in the custom ERP or stays in an accounting package.
Integration map
How does a custom ERP connect to MES, WMS, CRM and partners?
The ERP sits at the business level. Each connection is a contract that says which system sends what, when, and which one wins in a conflict.
Warehouse (WMS)
- ERP sends shipping and receiving orders
- WMS returns picks, packs, putaways and counts
- Bins and handling units stay in the WMS
- Stock value and availability stay in the ERP
Customers (CRM and ecommerce)
- CRM owns leads, contacts and opportunities
- ERP owns credit limits, prices, orders and invoices
- Won quotes become sales orders through one API
- Order status flows back for sales and support teams
Trading partners (EDI)
- Purchase orders received as X12 850
- Ship notices sent as X12 856
- Invoices sent as X12 810
- Every document stored with its acknowledgment
Finance and reporting
- Journal postings to the general ledger
- Bank payments and statements
- Read replicas or a warehouse for reporting
- Audit trail of who changed which record
System of record
Which system owns which record?
We agree this list before writing any integration. Two systems that both think they own a record is the most common cause of ERP data drift.
Custom ERP owns
- Item master, bills of materials and routings
- Sales and purchase orders
- Inventory quantities and valuation
- Customer credit and contract prices
MES owns
- Work order execution on the line
- Actual material consumption
- Scrap, rework and downtime reasons
WMS owns
- Bin locations and handling units
- Pick, pack and putaway tasks
- Cycle count results before approval
CRM owns
- Leads, contacts and activities
- Opportunities and quotes before acceptance
- Marketing consent preferences
EDI documents
Which EDI documents does the ERP exchange with partners?
Supplier and retail partners commonly exchange these X12 transaction sets. Each one maps to a document in the ERP and needs a defined response when it fails validation.
| Code | Name | Typical use |
|---|---|---|
| 850 | Purchase Order | Customer orders received into the ERP as sales orders, or your orders sent to suppliers |
| 855 | Purchase Order Acknowledgment | Confirms, changes or rejects order lines before anything ships |
| 856 | Ship Notice/Manifest | Tells the receiver what is on each shipment, down to cartons and lots |
| 810 | Invoice | Bills the partner from the shipped quantities, not the ordered ones |
| 846 | Inventory Inquiry/Advice | Shares stock availability with partners that sell your products |
Failure points
Where do custom ERP projects go wrong?
The problems we plan around from the first sprint.
Challenge
The team rebuilds the general ledger, tax and payroll that a packaged system already does well.
Agnotic approach
We keep commodity finance in a packaged system unless there is a clear reason not to, and build only where your process differs.
Challenge
The same customer or item exists in three systems with three codes.
Agnotic approach
One system of record per entity, agreed in writing, with cross-reference tables for partner and legacy codes.
Challenge
An integration retries and posts the same receipt or invoice twice.
Agnotic approach
Every message carries a business key, and the ERP rejects or merges duplicates instead of posting them again.
Challenge
Inventory value in the new ERP does not match finance's figures after go-live.
Agnotic approach
The valuation method is agreed with finance first, and opening balances are reconciled line by line before cutover.
Challenge
Cutover happens with open orders, part shipments and unreceived purchase orders in flight.
Agnotic approach
A cutover plan lists every open document type and how it is closed, migrated or recreated, rehearsed on a copy of production data.
Challenge
Custom code for one customer's process spreads into every module.
Agnotic approach
Customer-specific rules live in configuration or a rules module, not scattered through order, pricing and invoice code.
Modules we build in a custom ERP
Modules we design and build, alone or around a packaged core.
Inventory and lot tracking
Stock by location, lot and serial number, with movements traceable from receipt to shipment.
Order management
Quotes, sales orders, allocations, back orders and returns, with your pricing and approval rules.
Purchasing and receiving
Requisitions, purchase orders, receipts and three-way match with supplier invoices.
Production planning
Bills of materials, routings, work orders and capacity, connected to the MES on the line.
Roles and approvals
Role-based access, approval limits and segregation of duties between ordering, receiving and paying.
Ledger postings and audit trail
Journal entries for every stock and invoice movement, with a record of who changed what and when.
Data migration
Moving off a legacy ERP
Most custom ERP work replaces something older. These are the rules we follow when we move the data.
- Migrate master data and open documents; keep closed history in a read-only archive unless users need it daily
- Keep the archive searchable for as long as finance and tax records must be retained
- Clean duplicates and dead items in the old system before extraction, not after load
- Map every legacy code to its new value in a table your team can review
- Reconcile stock quantities, open orders and customer balances against the old system before sign-off
- Rehearse the full migration at least once on a copy of production data before cutover
What sizes this build
What drives the cost of custom ERP development?
We do not publish prices or offer an ERP calculator. These are the inputs we size a custom ERP build from on the scoping call.
Route
Extending a packaged ERP, building modules beside it, or building a full custom ERP.
Modules in scope
Which modules are in the first release and which wait for later ones.
Integrations
MES, WMS, CRM, ecommerce, banks and EDI partners, and how clean their APIs or file formats are.
Data migration
How many legacy systems, how much history and how much cleaning the data needs.
Sites and entities
Warehouses, plants, legal entities, currencies and languages to support.
Controls
Approval rules, segregation of duties and audit requirements from your finance team or auditors.
Who it is for
Which businesses build or extend an ERP with us?
Companies whose operations have outgrown spreadsheets around a packaged system.
Manufacturers
Make-to-order and engineer-to-order plants whose planning does not fit standard production modules.
Distributors and wholesalers
Businesses with contract pricing, rebates and EDI partners that expect exact documents.
Rental and service businesses
Companies tracking assets out on hire or technicians in the field, alongside stock and invoices.
Growing product companies
Teams moving off an entry-level accounting package and spreadsheets onto something they own.
Companies after an acquisition
Groups running several ERPs that need one operational layer while ledgers are consolidated.
Engagement
From scoping call to first release
From the processes that hurt today to modules your team runs.
1.
Scoping call
We hear which processes run outside the ERP today and why, and which systems are involved.
Scope2.
Process and data mapping
We map the processes, agree the system of record for each entity and pick the route from the decision table.
Map3.
Fixed-scope first release
Master data plus the one module that differs, connected to the systems it needs and tested with real users.
Build4.
Extend and hand over
Further modules, migration and cutover, then code, runbooks and support to your team or ours.
ExtendStandards
Standards behind our ERP integrations
Public standards that shape how the ERP talks to the shop floor and to trading partners.
ANSI/ISA-95IEC 62264ASC X12GS1 GTIN
Facts and sources
Which facts shape custom ERP work?
Standards and rules behind the integration and migration decisions on this page, each linked to its primary source.
ISA-95, also published as IEC 62264, is an international set of standards for integrating enterprise logistics systems with manufacturing control systems, and it outlines how an enterprise can set up an interface to communicate between those layers.
Source: ISA, ISA-95 Standard: Enterprise-Control System IntegrationISA-95 Part 2 specifies the interface content exchanged between manufacturing control functions and other enterprise functions, meaning the interface between level 3 manufacturing systems and level 4 business systems.
Source: ISA, ISA-95 Standard: Enterprise-Control System Integration (Part 2)ASC X12 publishes the Purchase Order (850), Ship Notice/Manifest (856) and Invoice (810) transaction sets, each of which establishes the format and data contents of that business document for use in electronic data interchange.
Source: X12, Transaction SetsThe IRS says records that support an item of income, deduction or credit on a tax return must generally be kept until the period of limitations for that return runs out, and employment tax records for at least 4 years after the tax becomes due or is paid, whichever is later.
Source: IRS, How long should I keep records?
Frequently Asked Questions
We do not publish a price or use an ERP calculator. Cost follows the route you choose, the modules in the first release, the integrations, the data migration, the number of sites and entities and the controls your finance team needs. You get a written proposal after the scoping call.
It depends on the route and on how many modules and integrations the first release needs, so we agree a fixed first release on the scoping call rather than quote the whole program. Building master data plus one module first gets real users working on it early.
Yes, and that is often the better choice. We build on the vendor's supported extension points and APIs, so your extensions survive vendor updates, and we regression test them through our ERP testing service.
Usually, yes. General ledger, tax and payroll change with regulation and rarely set a business apart. We normally post journal entries from the custom modules into your packaged ledger, unless there is a clear reason to bring the ledger in.
Yes. We agree which system owns each record, then build the interfaces: work orders out to the MES and actual consumption back, shipping orders out to the WMS and picks and counts back. Neither system has to be replaced.
We migrate master data and open documents, keep closed history in a searchable archive, map every legacy code in a table your team reviews and reconcile stock, open orders and balances before sign-off. The migration is rehearsed on a copy of production data first.
Yes. A typical first release is the item master, locations and the one module that is the reason for building, such as production planning or contract pricing, connected to the systems it needs.