EDI, e-commerce, a data standard, and a transport protocol often appear together, but they are not interchangeable. That confusion makes simple questions look harder than they are. Purchase order PO7421 travels from a buyer's ERP as an X12 850, clears its control totals, survives a mapping error and a replayed control number, and leaves behind an audit record a lawyer could read. Keeping those four ideas apart is what exam and interview questions on this topic almost always test.
Electronic Data Interchange inside e-commerce
E-commerce is commercial activity conducted through electronic systems. B2B connects businesses, B2C a business and consumers, C2C consumers, and C2B an individual and a business. EDI mainly supports repeatable B2B exchanges.
Electronic Data Interchange is computer-to-computer exchange of structured business documents in an agreed format. A portal order is e-commerce but not automated EDI. An emailed PDF is electronic but still needs human interpretation, extraction, or re-entry.
Term | What it controls | Example |
|---|---|---|
Business document | Commercial purpose | Purchase order |
Syntax standard | Field and segment structure | ANSI X12 or UN/EDIFACT |
Transport | How the message travels | AS2, SFTP, or VAN |
Business application | Where the transaction begins or ends | ERP or order-management system |
EDI architecture and the document lifecycle
An EDI flow has five layers. Source data begins in the buyer's ERP. A mapper validates fields and converts them into the agreed schema. The result is a standard EDI document, which secure transport carries to the partner. The supplier then translates it into its own order system. A trading-partner agreement fixes identifiers, standard versions, required fields, acknowledgements, and exception handling.
In the worked flow, an X12 850 is the purchase order. A 997 functional acknowledgement confirms syntactic receipt, while an 855 communicates business acceptance or a requested change. The 856 is an advance ship notice, and the 810 is an invoice. A 997 therefore does not say that the supplier accepted the order lines.
Keep standards separate from transport. X12 and EDIFACT structure messages. AS2, SFTP, and a value-added network carry them. An API is another integration interface and can coexist with EDI. AS2 itself rides on HTTP, so an EDI transfer is an application-layer exchange underneath, and Application Layer MCQs: 12 Solved DNS, HTTP, Email drills that layer.
EDI purchase-order worked example: PO7421
The mapper produces this simplified X12 850:
ST*850*0007~
BEG*00*SA*PO7421**20260115~
REF*DP*42~
PO1*1*120*EA***SK*KB104~
PO1*2*80*EA***SK*MS220~
CTT*2~
SE*7*0007~ST opens an 850 with control 0007. BEG identifies PO7421, REF carries department reference 42, and the two PO1 segments order 120 units of KB104 and 80 units of MS220.
Check the controls. ST02=0007 matches SE02=0007. SE01=7 is correct because seven segments run from ST through SE. CTT01=2 matches the two PO1 lines. Ordered quantity is 120 + 80 = 200 units.
The buyer sends PO7421 at 09:55 IST. The supplier returns a 997 at 10:02 confirming syntax receipt, then an 855 at 10:08 accepting both lines. The 856 reports KB104 as 3 cartons of 40 and MS220 as 4 cartons of 20: 3 x 40 + 4 x 20 = 120 + 80 = 200 units in 3 + 4 = 7 cartons. The 810 bills the same 200 units.
EDI validation worked example: control totals, errors and replay protection
Suppose a gateway receives 1,200 EDI documents. On the first attempt, 1,164 pass, 24 fail because the partner code is unmapped, and 12 repeat an already processed interchange control number. First-pass acceptance is 1,164 / 1,200 x 100 = 97%. Exceptions total 24 + 12 = 36, so the exception rate is 36 / 1,200 x 100 = 3%.
After correcting and reprocessing the 24 mapping errors, accepted documents become 1,164 + 24 = 1,188. The final accepted rate is 1,188 / 1,200 x 100 = 99%. The 12 duplicates remain quarantined, and 12 / 1,200 x 100 = 1%.
The gateway must not silently post a duplicate. Unique interchange control numbers plus an idempotency record ensure that replaying a message does not create a second business transaction.
EDI security controls and what each one proves
Each security property needs a suitable control:
Property | Practical controls |
|---|---|
Confidentiality | Encryption in transit and at rest |
Integrity | Hashes and digital signatures |
Authentication | Partner certificates or mutually authenticated identities |
Authorization | Least privilege, role-based access, and partner allowlists |
Availability | Queues, retries, monitoring, and recovery |
Replay resistance | Unique control numbers and idempotency checks |
If an attacker changes KB104 from 120 to 1,200 after signing, signature verification fails. Resending control 0007 triggers the duplicate check. An unapproved partner identity is rejected before translation into the ERP. Encryption proves nothing about origin: it decides who could read PO7421, not who sent it, which is why the signature and the control number are the parts that survive a dispute.
Non-repudiation is a claim about evidence, not a flag a protocol can set. A digital signature, a trusted timestamp, a signed receipt such as the AS2 message disposition notification, and a preserved audit trail together make it hard for a partner to deny sending or receiving PO7421. No single one of them settles a dispute by itself.
Cyber-law concepts around electronic commerce
Cyber-law analysis around EDI turns on a handful of principles, and each one has a concrete test. An electronic record counts as a record when it can be retained and reproduced in the form it was generated in. An electronic signature attributes a document to a signer. Attribution asks whose system sent the message, and that is settled by the authenticated partner identity on the connection, not by the order number printed inside the document. Dispatch and receipt fix the two instants a contract cares about: PO7421 left the buyer at 09:55 IST and the 997 evidences receipt at 10:02, seven minutes apart. Retention decides how long that evidence stays available, and data minimisation limits how much personal data the record carries in the first place.
For PO7421, the audit record should retain partner SUP-17, document type 850, control 0007, receipt time 2026-01-15T10:02:00+05:30, validation result PASS, and a hash computed from the stored payload. The hash is derived from that payload rather than supplied by hand, and the retention period comes from the trading-partner agreement and the applicable rules rather than from a convenient default.
The boundaries matter. Encryption controls who can read a message. Signatures help detect alteration and establish origin. A retention policy preserves evidence. What none of them decides is the outcome of a dispute: that rests on the applicable law, the trading-partner contract, and the facts, with the technical controls supplying the evidence.
EDI versus APIs, portals and email: exam and interview traps
These mechanisms can coexist, so compare their properties.
Dimension | EDI | API | Portal or email |
|---|---|---|---|
Structured schema | EDI standard | API contract | Portal fields may be structured; emailed PDF is not |
Automation | Usually system-to-system | Usually system-to-system | Often human-assisted |
Acknowledgement | Technical and business messages | Response, callback, or event | Status or human reply |
Partner onboarding | Mapping and agreement | Credentials and integration | Account or address setup |
Latency pattern | Batch or near-real-time | Synchronous or asynchronous | Workflow-dependent |
Exception handling | Validation queue and acknowledgements | Error, retry, or queue | Often manual |
ST02=0007, SE02=0007, and SE01=7 pass the envelope checks, but a 997 does not prove acceptance of both lines. The 36 first-pass exceptions out of 1,200 equal 3%. Encryption alone does not detect every replay or prove business acceptance.
Common traps have simple fixes: EDI is not a VAN; syntax is not transport; an emailed PDF is not structured EDI; technical receipt is not business acceptance; e-commerce is broader than EDI; and secure delivery is not legal compliance. For where this topic sits in a wider syllabus, see UGC NET Computer Science Syllabus Areas and Course Map, and the CS Fundamentals for Placements collection lists the placement-focused study routes.
Electronic Data Interchange: the short version and next step
Keep one chain in mind: business event, structured document, mapping, secure transport, acknowledgement, audit evidence. Two numbers hold the example together: 120 + 80 = 200 ordered units on PO7421, and 1,164 of 1,200 documents accepted on the first pass, which is 97%.
Placement-focused readers can continue with CS Fundamentals for Placements by Sanchit Sir, whose curriculum includes application-layer, network-security, and cyber and information-security material. ZERO TO HERO is the broader multi-subject route for anyone rebuilding several subjects at once.
