Operations teams
“A supplier operations team can see partner setup, validation, exceptions, and QuickBooks handoff in one workspace instead of chasing spreadsheets.”
EDI Reference Library
Explore high-intent guides by ICP, document type, partner onboarding requirement, and QuickBooks workflow.
Each entry includes the EDI code, transaction name, plain-language description, direction (inbound/outbound), and supported status. All transaction sets marked ✓ are available in SignalEDI plans. Where a detailed integration guide exists, a link is provided.
HIPAA Mandated
Healthcare EDI transaction sets are defined by HIPAA and required for all covered entities conducting electronic healthcare transactions. SignalEDI supports HIPAA-mandated ANSI X12 5010 transactions on the platform, with encryption for data in transit, access controls, and audit logging on supported flows — see the Healthcare EDI hub and security documentation for deployment responsibilities.
| Code | Name | Description | Direction | Supported | Guide |
|---|---|---|---|---|---|
| 837P | Professional Claims Daily | Electronic submission of professional/physician claims to insurance payers. Replaces the CMS-1500 paper form. Used by physician practices, mental health providers, labs, and other professional services. | Outbound | ✓ | Guide → |
| 837I | Institutional Claims Daily | Electronic submission of institutional claims for hospital and facility-based services. Replaces the UB-04 paper form. Used by hospitals, skilled nursing facilities, home health agencies, and hospice organizations. | Outbound | ✓ | Guide → |
| 837D | Dental Claims Daily | Electronic submission of dental claims to insurance payers. Replaces the ADA dental claim paper form. Used by dental practices, orthodontists, oral surgeons, and dental group practices. | Outbound | ✓ | |
| 835 | Electronic Remittance Advice (ERA) Per payment cycle | Payment explanation sent by payers to providers after claim adjudication. Contains payment amounts, contractual adjustments, patient responsibility, denial reason codes, and claim-level payment details. Enables automated payment posting without manual entry. | Inbound | ✓ | |
| 270 | Eligibility Inquiry Real-time / per visit | Request sent by a provider to a payer to verify a patient's insurance coverage and benefits before an appointment or procedure. Real-time eligibility verification reduces insurance-related claim denials and front-desk errors. | Outbound | ✓ | |
| 271 | Eligibility Response Real-time / per visit | Response from a payer to a provider confirming insurance eligibility, coverage details, deductible status, copay/coinsurance amounts, and benefit limitations. Returned in response to an EDI 270 inquiry. | Inbound | ✓ | |
| 278 | Prior Authorization Request & Response Per auth request | Used to request prior authorization (pre-approval) from a payer before providing certain services. The payer responds with an approval, denial, or pending status. Automating prior auth reduces turnaround time and administrative burden. | Bidirectional | ✓ | |
| 276 | Claim Status Inquiry Per claim | Request sent by a provider to check the processing status of a previously submitted claim. Eliminates the need to call payer call centers and enables automated follow-up on outstanding claims. | Outbound | ✓ | |
| 277 | Claim Status Response Per claim | Response from a payer indicating whether a claim is pending, in process, paid, or denied. Returned in response to an EDI 276 inquiry. Also used for unsolicited claim status updates. | Inbound | ✓ | |
| 820 | Payment Order / Remittance Per payment cycle | Used for premium payments from employers to health plans, and for bulk payment remittance in healthcare payer-to-provider contexts. Enables electronic premium payment without checks. | Bidirectional | ✓ | |
| 834 | Benefit Enrollment & Maintenance Per enrollment event | Used by employers and benefits administrators to enroll employees in health insurance plans, update coverage, add dependents, and terminate coverage. Keeps member rosters in sync between HR systems and health plans. | Outbound | ✓ |
ANSI X12
Retail and supply chain EDI transaction sets are required by major retailers including Walmart, Target, Home Depot, Kroger, and hundreds of other buyers. SignalEDI supports the full retail EDI workflow from purchase order receipt through invoice and remittance.
| Code | Name | Description | Direction | Supported | Guide |
|---|---|---|---|---|---|
| 850 | Purchase Order Per order | The foundational retail EDI transaction. Sent by a retailer or buyer to a vendor to order products. Contains item numbers, quantities, pricing, ship-to addresses, and delivery requirements. Every retail EDI integration starts here. | Inbound | ✓ | |
| 855 | Purchase Order Acknowledgment Per order | Vendor's confirmation of a received purchase order. Can accept, reject, or modify the PO. Required by many large retailers within 24–48 hours of PO receipt. | Outbound | ✓ | |
| 856 | Advance Ship Notice (ASN) Per shipment | Sent by a vendor to notify a retailer that a shipment has been dispatched before it arrives. Contains detailed packing information — case quantities, UPC codes, pallet configurations, and carrier details. Required by most major retailers before warehouse receipt. | Outbound | ✓ | |
| 810 | Invoice Per shipment / order | Electronic invoice sent from a vendor to a buyer. Replaces paper invoices for B2B transactions. Contains line-item pricing, quantities, terms, and remittance instructions. | Outbound | ✓ | |
| 846 | Inventory Inquiry / Advice Periodic / on-demand | Used to share current inventory levels between trading partners. A vendor can send an 846 to notify a retailer of available inventory, or a retailer can request inventory data from a vendor. | Bidirectional | ✓ | |
| 860 | Purchase Order Change Request Per change event | Sent by a buyer to modify a previously issued purchase order — changing quantities, items, delivery dates, or pricing. Requires a corresponding 865 response from the vendor. | Inbound | ✓ | |
| 861 | Receiving Advice / Acceptance Certificate Per receipt | Sent by a receiver (retailer/warehouse) to confirm what was actually received from a shipment, versus what was expected per the ASN. Used to identify discrepancies for chargebacks or shortage claims. | Inbound | ✓ | |
| 832 | Price/Sales Catalog Per catalog update | Electronic product catalog transmission. Vendors send an 832 to share product listings, prices, and availability with retail buyers. Enables catalog synchronization without spreadsheet exchange. | Outbound | ✓ | |
| 844 | Chargeback / Debit Memo Per chargeback event | Sent by a retailer to a vendor to document a chargeback — a deduction from payment for violations of routing guides, labeling requirements, ASN compliance, or other trading partner rules. | Inbound | ✓ |
Infrastructure
General purpose EDI transaction sets handle acknowledgment, error reporting, and infrastructure-level communication between trading partners. Every EDI implementation relies on these transactions for reliable, error-free data exchange.
| Code | Name | Description | Direction | Supported | Guide |
|---|---|---|---|---|---|
| 997 | Functional Acknowledgment Per transaction set | The EDI 'receipt confirmation.' Sent by a receiver to acknowledge that a transaction set has been received and syntactically validated. The 997 does not confirm the content is correct — only that the transaction was received without format errors. | Bidirectional | ✓ | |
| 999 | Implementation Acknowledgment Per transaction set | An enhanced acknowledgment that validates both the syntax and the implementation guide compliance of a received transaction. Replaces 997 for HIPAA 5010 transactions — required for all healthcare EDI acknowledgments. | Bidirectional | ✓ | |
| 824 | Application Advice Per error event | Reports application-level errors in received transaction sets — errors related to the business data content rather than the EDI syntax. Used when a trading partner can receive and parse an EDI document but the content fails business validation rules. | Bidirectional | ✓ | |
| 214 | Transportation Carrier Shipment Status Per status event | Used by carriers and logistics providers to report shipment status events — pickup, in transit, out for delivery, delivered. Enables automated shipment tracking without carrier API polling. | Inbound | ✓ |
All healthcare transaction sets comply with ANSI X12 Version 5010, as mandated by HIPAA and CMS. Retail and supply chain transactions support both Version 4010 and 5010 for backward compatibility with legacy trading partner systems. SignalEDI automatically handles version negotiation with trading partners — no manual version configuration required.
All transaction sets above are supported in SignalEDI plans. Healthcare EDI included in every plan. No EDI expertise required — send JSON, receive EDI. 30-day free trial available with no credit card required.
No credit card required · No setup fees · Cancel anytime
Trust & proof
SignalEDI keeps the public promise consistent across every route: real-time processing, transparent monthly plans, no per-document fees, QuickBooks-friendly handoffs, and core healthcare X12 workflows on paid plans.
Operations teams
“A supplier operations team can see partner setup, validation, exceptions, and QuickBooks handoff in one workspace instead of chasing spreadsheets.”
Healthcare billing
“837, 835, and 270/271 workflows are explained in plain English, with HIPAA-aware handling and a documented BAA review path for diligence.”
Developer teams
“JSON/CSV in and X12 out, with API docs, webhooks, real-time status, and validation responses that make EDI feel like modern infrastructure.”
© 2026 SignalEDI Inc. All rights reserved.