The operating problem
ERP systems are designed to enforce broad commercial and operational structures. Real businesses still encounter processes that do not fit neatly into standard screens: design imports, product setup, warehouse assignment, technical validation, supplier files, exception review and temporary operational states. Teams often bridge the gap with spreadsheets because replacing or customising the ERP feels too risky.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 09 Jul 2026 · Last reviewed 09 Jul 2026Identify the boundary the ERP should own
A support layer works only when responsibility is clear. The ERP may own stock codes, orders, customers, inventory balances or financial posting. The surrounding application may own draft design data, validation results, review status and exception evidence. Duplicating ownership creates reconciliation problems.
- Name the master system for every important field.
- Treat temporary staging records as temporary rather than shadow masters.
- Store destination identifiers and responses after successful hand-off.
Stage uncertain data before posting
External files and manual captures often contain missing, duplicated or contradictory information. Posting directly to production turns a data-quality problem into an ERP correction problem. A staging area allows the system to parse, normalise and validate records without pretending they are ready.
- Preserve the original source file or payload for traceability.
- Separate parse errors, business-rule failures and destination rejection.
- Allow users to review exceptions without editing raw source evidence invisibly.
Make specialist rules visible
Experienced users often apply undocumented rules when selecting warehouses, routes, products, dimensions or classifications. A support system can encode the stable parts, show why a recommendation was made and leave uncertain cases for human judgement. The goal is not to eliminate expertise; it is to stop hiding it.
- Record the rule version used for each decision.
- Expose the inputs and reasoning behind validation results.
- Treat controlled overrides as evidence for future rule refinement.
Design idempotent hand-off
A failed response or timeout creates uncertainty: did the ERP receive the transaction or not? Retrying blindly can create duplicates. Integration must use destination capabilities, transaction references and reconciliation queries to make repeated attempts safe.
- Create a stable external transaction identifier.
- Distinguish not-sent, sent, accepted, rejected and unknown states.
- Provide a recovery workflow for unknown outcomes.
Exception review is part of the product
Most integrations are designed around valid records. Operational value often depends on how invalid or incomplete records are handled. A useful exception screen groups related issues, explains what is wrong, identifies ownership and preserves the final decision.
- Do not bury business exceptions inside technical logs.
- Route issues to the role able to resolve them.
- Keep a searchable history of corrections and overrides.
Use support layers to reduce, not multiply, shadow systems
The support application should retire uncontrolled copies and manual steps, not become another disconnected database. Its purpose, data retention and ownership must be limited to the operational gap it closes. Reports should reconcile against the ERP rather than quietly becoming an alternative truth.
- Define which staging data can be archived after posting.
- Reconcile totals and key identifiers regularly.
- Avoid adding unrelated modules merely because the support tool is convenient.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The ERP already supports the process with configuration or a standard module.
A custom layer may add avoidable complexity.
Use the ERP capability unless a proven operational gap remains.
Input files need validation and human review before posting.
Staging and exception control are justified.
Build a preflight layer with explicit hand-off states.
Rules depend on specialist knowledge outside ERP configuration.
A visible recommendation and override workflow may reduce risk.
Encode stable rules and audit human decisions.
The team cannot tell whether failed integrations posted successfully.
The current hand-off is operationally unsafe.
Introduce transaction identity, idempotency and reconciliation.
Evidence that the current approach is becoming risky.
- Users correct rejected records directly in production without preserving the source issue.
- The same master data is maintained in both the ERP and support database.
- Retries can post the same transaction more than once.
- Business exceptions appear only in developer logs.
- Spreadsheets remain the real approval and rule engine after integration.
What to clarify before commissioning work.
- Define ERP-owned and support-layer-owned data.
- Capture original input and parse it into staging records.
- Write explicit validation and rule results.
- Model sent, accepted, rejected and unknown hand-off states.
- Create user-facing exception review and controlled overrides.
- Reconcile posted records against destination responses.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Is a support layer the same as replacing the ERP?
No. The ERP remains authoritative for agreed records and transactions. The support layer controls preparation, validation, review and traceable hand-off.
Can the system write directly to ERP tables?
That depends on vendor support and governance, but supported APIs, import mechanisms or approved integration paths are generally safer than undocumented direct writes.
What happens when the ERP is unavailable?
The support layer should retain staged work, prevent ambiguous duplicate posting and expose a controlled retry or reconciliation process.
How do we stop the support layer becoming another legacy system?
Keep its boundary narrow, document ownership, use maintainable architecture, preserve audit evidence and avoid duplicating master-data responsibilities.