EDI integration with a custom ERP is entirely doable. There is no connector to buy, so the work is engineering: a translation layer between your system's data model and your partners' X12 documents, plus transport, acknowledgments and monitoring. What determines cost is not the ERP's age. It is the number of trading partners, the number of document types, and how far your internal data model is from the shape those documents expect.
This page is written for the company that has already discovered the gap: the EDI vendor asked which ERP you run, heard the answer, and went quiet. The hub page covers EDI integration across all three build paths; this one is about the path with no product shortcut.
Why your ERP has no connector, and why that is not a defect
Connector vendors build for markets. A maintained connector exists where thousands of companies run the same ERP and the same five documents. NetSuite, SAP, Acumatica, QuickBooks — the volume justifies the maintenance.
A legacy ERP or homegrown ERP has no connector because it is a market of one. The system was built around your operations: your order lifecycle, your lot tracking, the way your warehouse confirms a pick. That specificity is a business asset and an integration problem at the same time. There is no vendor whose roadmap includes your tables.
Two consequences follow. First, nobody else's implementation experience transfers cleanly; your map is your map. Second, the integration is an engineering project with a defined scope, not a subscription with a setup fee. Companies that approach it as the second thing pay twice.
The four places a custom ERP actually meets EDI
Every EDI relationship with a custom or legacy ERP touches the same four surfaces. Scope is the sum of them.
Order intake
The 850 purchase order arrives and must become an order in your system: customer, ship-to, lines, quantities, prices, dates. The hard part is identity. The partner's item number, your SKU, the UPC on the line — one of them has to win, and the cross-reference has to exist before the first order lands.
Inventory and item master
Availability promises and item data flow both directions in most programs. If your item master carries no GTIN or no partner-specific item number, the integration project quietly includes building that data. It is the most commonly underestimated part of the scope.
Shipping confirmation
The warehouse ships; an 856 advance ship notice has to leave, matching the physical pallet: hierarchy, quantities, SSCC-18 label numbers, carrier and PRO number. This is where chargebacks are generated, and where a custom ERP's pick-confirmation flow either feeds the ASN cleanly or gets rebuilt until it does. For warehouses receiving 940 shipping orders from retail partners, the same surface runs in reverse: the 940 becomes a shipment order inside your system, and the 945 shipping advice reports back what actually shipped.
Invoicing
The 810 invoice goes out and has to match the 850 it bills against: same quantities as shipped, same prices as ordered, same charge structure as the contract. The invoice is the last document in the chain and the first place a disagreement upstream becomes money.
Three approaches, and the honest cost of each
Middleware with a custom adapter. An iPaaS or EDI middleware handles transport, translation infrastructure and monitoring; your engineering (ours, or yours) builds the adapter between the middleware and your ERP. Recurring subscription cost, real upfront build cost, and the fastest route when the middleware already speaks your partners' dialects. Choose it when you want the operational layer rented and the ERP-side work owned.
Direct engineered integration. Your systems talk to a VAN or AS2 endpoint through a translation layer built for your data model: maps per partner, acknowledgment monitoring, a reconciliation path for failures. Higher upfront cost, no per-document subscription, and the layer is an asset you own. This is the path that pays when partner count grows, when documents are non-standard, or when the integration sits on the revenue critical path. At a non-asset 3PL with major US retail accounts, prebuilt maps for the 850, 856, 810, 940 and 945 cut trading-partner onboarding from 8–10 weeks to 12 days (case C05).
VAN plus manual bridge. Documents land in a mailbox; someone re-keys them. Every company runs this path at the start of an EDI relationship, and it is a legitimate bridge for one partner and low volume. The cost is linear in volume and invisible until it is large: re-keying errors become disputes, and the person doing it becomes a single point of failure.
When a connector is right: your ERP actually has one, or is close enough that a vendor will support you, your partners are on the vendor's list, and your process matches the connector's model. In that case the connector wins on price and speed. That situation is not the one this page is for.
What breaks after go-live
This is the section no vendor page carries, because the failures happen after the sale. Four patterns, all seen in production.
The item master drifts out of sync. The cross-reference table was complete at go-live. Then your catalog changed: new SKUs, discontinued items, a UPC reassigned after a packaging change. Orders start failing line by line, and the error reads as an EDI problem while the cause is a data problem. The fix is a process, not a map: item changes get an EDI cross-reference step, or the integration validates the catalog on a schedule and reports gaps before partners hit them.
A partner changes a qualifier without notice. Implementation guides get revised; an N9 reference qualifier changes, a date moves between G62 qualifiers, a segment goes from optional to required. Your translator accepts the new shape or rejects the old one, and either way the breakage surfaces mid-flow, on live orders. Defensively: version-pin what you can, monitor acknowledgment codes for shifts in rejection reasons, and treat any new rejection signature as a guide change until proven otherwise.
The 997 nobody reads. A 997 functional acknowledgment says whether your outbound document was accepted. Most custom-ERP integrations send and never check. Rejections accumulate silently; the discovery comes as a phone call from the partner or a deduction on the remittance. The monitoring costs almost nothing. The absence of it is expensive.
The 4010-to-5010 upgrade that silently reorders your world. The version change in the envelope is the visible part. The invisible part is the partner guide that ships with it: stricter date formats, segments reordered or re-required, element lists revised. Maps validated against the old guide pass their tests and fail in production. The only reliable preparation is re-testing every map against the partner's new guide, not against the standard, and not against your VAN's translator.
What this costs and how long it takes
Scope drives cost more than anything else, and scope is the four surfaces above multiplied by partner count and document count. A single partner with the standard three documents and a reachable data model is a project measured in weeks. A 3PL program with several retail chains and five document types is measured in months, including each partner's certification sequence.
A realistic planning range for a first custom-ERP engagement: two to four months from kickoff to first production documents with one partner, with each additional partner compressing as the layer matures. If a quote for this scope is dramatically shorter, ask what is being left out — usually acknowledgment monitoring, the item-master process, or the partner's certification cycle.
When you should not hire us
One stable trading partner, a supported ERP, a standard document set and no roadmap pressure on the integration: buy the connector, and keep the engineering budget for something the connector cannot do.
Equally honestly: if your partner count is one and your volume is low, the VAN-plus-manual bridge is defensible for a while. The trigger to build is not purity. It is when the manual cost, the error cost or the onboarding delay starts exceeding the cost of the layer.
How we start
The two-week diagnostic at $7,500 maps your data model against your partners' guides and produces a verdict: what the build is, what it costs, and which surfaces carry the risk. The findings document is yours either way. For a company with a custom or legacy ERP, the audit usually pays for itself in scope it prevents you from discovering mid-project.
Written by the CrunchCode engineering team — the people who ran these integrations in production.