Custom Software With EDI Integration: What It Really Costs to Build

What EDI actually is once a real trading partner is on the other end

Electronic Data Interchange (EDI) is a set of fixed-format documents exchanged between businesses, mostly ANSI ASC X12 in North America and UN/EDIFACT everywhere else. A purchase order is an X12 850. The acknowledgement of that order is an 855. The advance ship notice is an 856. The invoice is an 810. The functional acknowledgement, the one that says "I received your file and it parsed", is a 997. That list is the part every vendor quotes on. It is the easy part. A competent parser for 850 and 810 is about two weeks of work.

Where the naive version breaks: you go live with a retailer. Their 850 arrives with the ship-to address in an N1 loop with qualifier ST. Your parser reads it, creates the order, everything is fine for three weeks. Then the retailer sends an 850 for a drop-ship order where the ST address is a consumer's home, and a second N1 loop with qualifier BT for the bill-to, and your code takes the first N1 loop it finds because that is what worked for twenty-one days. You ship 400 units of product to the retailer's corporate office. Nobody notices for six days because your integration never sent an 856, so the retailer's receiving system had no expectation to reconcile against. The chargeback for a missing or late ASN at a large grocery or general merchandise retailer is real money, often a percentage of invoice value per occurrence, and it is assessed per purchase order rather than per incident. The failure mode here is not a server going down. It is a silent semantic misread that shipped wrong for a week.

The second thing that breaks: you send an 810 invoice, get a 997 back saying accepted, and assume you are paid. The 997 only means the syntax parsed. The 824 application advice, if your partner even sends one, is what tells you the invoice was rejected for a price discrepancy against the original 850. Teams that treat 997 as success sit on 90 days of unpaid invoices and do not find out until finance asks.

Every trading partner is a separate integration, and their spec is a PDF

There is no such thing as "supporting X12 850". There is supporting a specific partner's 850 implementation guide. The X12 standard defines segments and qualifiers, then each partner publishes a companion guide that says which segments are mandatory for them, which qualifiers they use, what their internal item numbers look like, and which of the standard's optional elements they will reject you for omitting. These guides are 40 to 200 page PDFs. They are not machine readable. They contradict themselves.

Practical consequences you should budget for. The same 850 from two partners will disagree on where the ship-date lives: one uses DTM with qualifier 002, another puts it in a PO4 loop, another sends a blanket order with releases in an 862 and expects you to know the 850 was informational. Unit of measure codes differ: one partner sends EA for each, another sends CA for case with a PO4 pack quantity you must multiply. Item identification differs: UPC in the LIN loop for one, their internal SKU for another, and you need a cross-reference table your ERP (Enterprise Resource Planning) does not have.

What a competent build does: it separates the parser from the mapper. The parser turns raw X12 into a neutral structured object and is written once. The mapper is per partner, is data-driven rather than hard-coded, and lives in config that a non-engineer can inspect. If you see a proposal where partner-specific logic is if (partnerId === 'ACME') branches inside the order service, that build will cost triple by partner number five. Realistic velocity from our delivery data: the first partner takes 3 to 5 weeks including certification. Partners 2 and 3 take 2 to 3 weeks each. By partner 6, with the mapping layer built, you are at 3 to 8 days each. The curve only bends if someone paid to build the mapping layer up front.

Transport is a 1990s problem you still have to solve

The document is only half of it. The connection is the other half, and it is where most timelines slip.

Options in the real world. AS2, defined in RFC 4130, is the most common direct method: HTTP with S/MIME signing and encryption, plus a Message Disposition Notification (MDN) that proves receipt. It requires X.509 certificates that you and your partner exchange, and those certificates expire. A certificate rollover with a large partner is a coordinated, scheduled event that takes weeks of email, and if you miss the window your inbound orders stop with a TLS or signature error at 2am on the expiry date. SFTP is common and simpler but has no acknowledgement layer, so you build your own file-received tracking. VANs (Value Added Networks) like SPS Commerce, TrueCommerce, Cleo or OpenText act as a post office: you connect once to them, they connect to everyone. Some partners still use AS1 over SMTP. Some large partners will only connect through a VAN they specify.

The interchange control numbers matter more than people think. The ISA13 interchange control number and GS06 group control number must be unique and, for some partners, strictly increasing. If your service redeploys and resets a counter, or two instances of your sender run concurrently and race, the partner rejects the interchange as a duplicate. That is a distributed sequence-generation problem rather than a formatting problem. Use a database sequence with a transactional reservation, not an in-memory counter, and never let two writers share a sender ID.

Also: X12 segments are terminated by a character you get from the ISA header itself, not a fixed newline. Partners use different element separators, sub-element separators and segment terminators. A parser that hard-codes ~ and * works until the day it does not.

Idempotency, replay, and the duplicate order problem

EDI is asynchronous and lossy in exactly the ways that cause duplicates. A partner's VAN retries. A file drops into your SFTP directory twice because a poller crashed between read and archive. A partner resends the entire day's batch because of an issue on their side, and you now have 300 850s you have already processed.

What a competent build does: deduplicate on the partner-supplied purchase order number (BEG03 in an 850) combined with the sender ID, not on a hash of the file, because the same logical order can arrive with a different control number. Store every raw inbound interchange immutably before parsing, keyed by ISA13, so you can replay it. Make processing idempotent so replaying the archive is safe and boring. Treat a resend of the same PO number with a different BEG02 purpose code (00 original vs 01 cancellation vs 04 change) as a distinct state transition rather than a duplicate, because change orders arrive as an 860 or as an 850 with purpose code 04 depending on the partner.

Failure mode most builds miss: partial batch failure. An interchange contains 50 transaction sets and set number 37 has bad data. Do you reject all 50 or accept 49? The 997 lets you accept or reject at the transaction-set level, and most partners expect exactly that granularity. All-or-nothing processing means one bad line item stops a whole day of orders.

Testing and certification is a calendar item, not a sprint task

This is the line nobody quotes. Before a partner turns on production EDI with you, they run a certification cycle: you send test documents to their test environment, a human at their end reviews them, sends back corrections, and you iterate. With a large retailer this is 2 to 6 weeks of elapsed time, most of it waiting. Their EDI coordinator has a queue. You will get one round of feedback per week if you are lucky. Some partners have testing windows and will not accept new certifications during Q4 peak.

You also cannot generate realistic test data yourself. You need their actual sample files. Ask for them on day one, in writing, before you write a line of code. Half the surprises in this work come from a segment that is not in the companion guide but appears in every real file they send.

Budget implication: for a project touching three partners, assume 6 to 10 weeks of calendar where your engineers are blocked on someone else's inbox. Good delivery plans stack partner certifications in parallel and use that time for the internal mapping tooling.

What this costs and what drives the number

These bands come from Digital Heroes delivery across 2,000+ projects.

A focused EDI capability added inside an existing product, with 2 to 4 partners and 3 to 5 document types (typically 850, 855, 856, 810, 997), runs $15,000 to $60,000. That assumes you already have an order model, a database and a deployment pipeline, and that you are connecting via SFTP or a VAN rather than standing up AS2 yourself.

EDI as part of a first release, where the surrounding order and inventory system is also being built, runs $50,000 to $130,000 in 10 to 16 weeks. The EDI work is roughly a third of that, and the rest is the domain model it plugs into.

A full platform, with a mapping UI, self-serve partner onboarding, AS2 in-house, a compliance and chargeback dashboard, and 10 or more partners, runs $150,000 to $350,000 over 6 to 12 months.

What specifically pushes this capability's number up, in order of impact. Partner count is the single biggest driver and it is superlinear early, sublinear late: going from 1 to 4 partners roughly doubles cost, going from 10 to 20 adds maybe 30 percent if the mapping layer exists. Document type breadth is next: adding 856 ASN generation is expensive because it requires packaging hierarchy (pallet, carton, item) and SSCC-18 barcode label generation on GS1-128 labels, which drags in physical printing and often a scale or WMS (Warehouse Management System) integration. Adding AS2 in-house instead of using a VAN adds $8,000 to $20,000 and ongoing certificate operations forever. Outbound is more expensive than inbound: parsing someone else's file is easier than producing one that passes their validation. And if your ERP is the actual source of truth, the ERP connector, not the EDI, is where the money goes.

When you should NOT build this

If you have fewer than five trading partners, no unusual document types, and a standard ERP or e-commerce backend, buy it instead of building it. SPS Commerce, TrueCommerce, Cleo Integration Cloud and Orderful will map your partners for you as a service. That is a monthly subscription plus per-document fees, and it buys you out of the certification cycles, the AS2 certificate rotations and the companion-guide archaeology. Get a real quote against your actual document volume and partner count before you compare it to a build, because the comparison is rarely close: the service works on day 30, the build works on day 120. If EDI is a cost of doing business for you rather than a product differentiator, stop reading and go get that quote.

Build custom when one of three things is true. First, EDI is your product: you are the platform other people connect through, and mapping speed is your moat. Second, your document flow is genuinely non-standard, for example EDI events must trigger real-time decisions inside your own system rather than land in an ERP inbox, and the round-trip through a VAN's batch schedule breaks your business. Third, you have partner volume where per-document VAN pricing has crossed into six figures a year, at which point the build pays back inside 18 months. Everyone else is paying for the privilege of maintaining a parser.

Middle path worth taking seriously: use a VAN for transport and partner mapping, and build only the thin layer that turns their normalized API into your domain events. That keeps the ugly part outsourced and the valuable part in-house, and it is what we recommend to most clients who come in asking for full custom EDI.

How to brief and vet a developer for this

Give them, before any estimate: the actual companion guides from each partner, real sample files (not spec examples), the list of document types with direction, the transport method each partner requires, and whether the ERP or your system owns order state. An estimate given without the companion guides is fiction.

Questions that expose someone who has never shipped EDI. Ask what a 997 actually confirms, and whether they would treat it as delivery confirmation. Anyone who says yes has never been paid late because of it. Ask how they generate ISA13 control numbers across multiple app instances. If the answer is not "a database sequence" or equivalent, they will ship duplicate-interchange rejections. Ask where the segment terminator comes from. If they say "it's a tilde", they have parsed exactly one file. Ask how they would handle an 850 with purpose code 04 for a PO already shipped. Ask what happens when transaction set 37 of 50 fails validation. Ask how long they expect certification with a large retailer to take, and treat any answer under two weeks as inexperience. Ask them to describe an 856 they built and what the packaging hierarchy looked like, because that is the document that separates people who have read about EDI from people who have done it.

One more: ask what they would do if the partner's spec and the partner's real files disagree. The correct answer is "map to the real files, log the deviation, raise it with their coordinator in writing, and never silently accommodate it in the parser." Anyone who says "follow the spec" will go live and immediately fail.