Electronic Data Interchange (EDI) streamlines the document exchange process by automatically transforming documents into standardized digital formats and removing manual intervention. Documents flow directly between computer applications in different organizations, eliminating the need for human involvement in sending or receiving them.
Celigo B2B Manager is a comprehensive EDI solution for managing and automating electronic data interchange (EDI) with trading partners. It enables businesses to exchange key business documents—such as purchase orders, invoices, shipment notices, and acknowledgments—using standard EDI formats like X12 and EDIFACT.
Powered by the Celigo integration platform, the solution handles document translation, validation, and secure transmission via protocols such as AS2, SFTP, and VAN. It also simplifies trading partner onboarding and provides centralized monitoring and error management. By connecting EDI transactions directly to ERP and other core systems, Celigo B2B Manager helps organizations increase efficiency, improve data accuracy, and scale their B2B operations with confidence.
You can optimize the use of B2B Manager by following the best practices given below at different stages of the project lifecycle:
Proper preparation before implementation ensures that EDI parsers, generators, and connectivity can be implemented efficiently and reduces rework during testing. Before configuring any EDI integration, you must gather and validate all required information or technical assets such as EDI sample files and business rules.
-
Prioritize real sample files over specifications: While EDI specification documents are required, they are often outdated or inconsistently implemented. Actual sample EDI files from the trading partner are critical for accurate parsing, validation, and testing.
-
Define business rules early: Clearly document transformation logic between the source (for example, NetSuite) and the destination systems. This includes unit conversions, conditional mappings, default values, and partner-specific exceptions. Finalizing these rules before mapping helps avoid downstream changes.
When onboarding a trading partner such as ABC Corp, the following technical assets and information must be collected during the planning/pre-implementation phase to ensure a successful integration.
|
Item no. |
Technical assets |
Details |
|
1. |
Documentation and sample files |
Gather all specifications and sample files early so that parsers and generators can create or validate rules correctly. |
|
2. |
Connectivity details |
|
|
3. |
EDI configuration information |
|
|
4. |
Integration and project requirements |
|
Celigo B2B Manager provides pre-built integration templates through the Celigo Marketplace to accelerate common B2B business processes.These templates support multiple EDI standards (X12 and EDIFACT) and are tightly aligned with NetSuite data models and best practices.
Where possible, start with a pre-built template rather than build an integration from scratch. These templates are designed using Celigo-recommended patterns, can seamlessly integrate with the Celigo B2B Manager NetSuite Suite Application and significantly reduce implementation time, risk, and maintenance effort.
The following templates for common NetSuite scenarios are available in the Celigo Marketplace (select By type as "Templates" and use search term "B2B Manager" :
-
NetSuite Order to Cash: EDI for B2B Manager (X12)
Supports inbound and outbound X12 transactions commonly used in the Order to Cash cycle (for example, 850, 855, 856, 810 docs).
-
NetSuite Procure to Pay: EDI for B2B Manager (X12)
Supports Procure to Pay scenarios, enabling inbound and outbound purchase-related EDI documents aligned with NetSuite procurement workflows.
-
NetSuite Order to Cash: EDI for B2B Manager (EDIFACT)
Provides EDIFACT-based Order to Cash flows tailored for trading partners operating in regions where EDIFACT is the preferred standard.
-
Faster implementation: Core flows, mappings, and EDI structures are already defined.
-
Standards-aligned design: Templates follow EDI best practices and Celigo recommended architecture.
-
NetSuite-ready mappings: Common NetSuite records and fields are pre-mapped, reducing custom work and can seamlessly integrate with the pre-built NetSuite Suite Application from Celigo.
-
Easier extensibility: Templates can be configured and extended to meet trading-partner-specific requirements without re-architecting the integration.
-
Lower long-term maintenance: Updates and enhancements are easier to manage compared to fully custom flows.
Refer to this guide in the Celigo Help Center for a comprehensive overview of B2B Manager for EDI integrations. This document aims to capture the process of getting started with, building, and best practices of setting up an EDI integration from the perspective of an individual/team that is doing the build. This article focuses on users who're familiar with building flows using the Celigo platform (integrator.io).
Inbound EDI configurations ("exports in Celigo terminology) are critical to ensure that incoming EDI documents are parsed, normalized, and transformed into a structure that downstream applications (such as NetSuite) can reliably consume. Following consistent inbound configuration patterns improves scalability, reduces partner-specific customizations, and simplifies long-term maintenance.
Avoid cloning or rebuilding file definition rules (FDRs) unless a clear gap exists. Reuse it, where possible, to ensure consistency across implementations and simplify FDR upgrades and support.
When implementing inbound EDI data flow or export steps for a trading partner:
-
Reuse existing Trading Partner (TP) profiles and File Definition Records (FDRs) whenever the trading partner is already available as an endpoint connection in Celigo.
-
Existing profiles and FDRs are pre-aligned with Celigo-recommended segment structures, validation rules, and partner-specific nuances.
If a trading partner-specific document definition is not available:
-
Select the generic document definition for the applicable EDI standard (for example, Generic X12 or Generic EDIFACT).
-
Refine segment usage and qualifiers using transformation logic rather than creating a custom FDR prematurely. Generic definitions provide a flexible base structure that can be extended through mappings and transformation scripts without locking the integration to a single partner’s implementation.
Inbound EDI documents often contain repeating segments, qualifier-driven data, and hierarchical structures that are not immediately suitable for ERP consumption. Transformation scripts are used to normalize and flatten the parsed EDI JSON into a predictable and mapping-friendly format.
The provided transformation script in the templates follows Celigo best-practice patterns and focuses on performance, reusability, and clarity.
Segment normalization patterns used in the script
The transformation logic categorizes segments into specific handling patterns based on how they appear in EDI documents.
A. Array to object (without qualifiers)
Some segments may repeat per the standard but are typically sent only once by the trading partner. In such cases, a single-element array is safely converted into an object.
Segments
-
ITD (Terms of Sale)
-
TD1 (Carrier Details)
-
PID (Product Description)
-
CTT (Transaction Totals)
Example
"ITD": { ... }
instead of
"ITD": [ { ... } ]
This simplifies NetSuite mappings by removing unnecessary array handling.
B. Array to object (with qualifiers)
Qualifier-driven segments require special handling. Multiple occurrences of the same segment are grouped and flattened using the qualifier value as part of the key.
Segments
-
REF (Reference Identification)
-
MAN (Marks and Numbers)
-
N9 (Extended Reference Information)
-
CAD (Carrier Detail)
Example
"REF_DP": { ... },
"REF_IA": { ... }
Always validate which qualifier values are actually used by the trading partner using sample files. Specifications alone are often insufficient.
C. Array to string (with qualifiers)
Some segments are best represented as simple key–value pairs rather than objects, especially when only one data element is relevant.
DTM segment
-
Qualifier: Date/Time Qualifier
-
Value: Date
Example
"DTM_011": "20240115"
This approach reduces mapping complexity while preserving semantic meaning.
D. N1 (Party) loops
The N1 loop is one of the most commonly repeated and customized structures in EDI.
Script behavior
-
Flattens N1 loops into entity-specific objects using the Entity Identifier Code
-
Merges nested address segments (N3, N4) into the parent entity
-
Extracts PER (Contact) information into meaningful keys
Example
"N1_ST": {
"Name": "ABC Warehouse",
"N3_Address Information 1": "123 Industrial Way",
"N4_City Name": "Dallas",
"PER_BD": "John Doe"
}
This structure allows direct mapping to Ship-To, Bill-To, or Vendor records in NetSuite.
E. Line-level segments and product identifiers
Line-level segments (PO1, LIN, IT1, RMR) often contain multiple product identifiers using repeating qualifier–value pairs.
Script capabilities
-
Supports up to 25 product identifiers per line
-
Dynamically converts qualifier-based identifiers into readable keys
-
Handles multiple formatting variations from different FDRs
Example
"Product/Service ID BP": "ABC123",
"Product/Service ID VP": "VENDOR456"
It eliminates hard-coded mappings and makes the solution partner-agnostic.
F. One-to-many scenarios (Multiple STs)
Some inbound files contain multiple transaction sets (ST segments) with shared header-level information.
-
Header fields should be preserved and repeated appropriately across transaction sets
-
The script ensures header-to-line consistency while maintaining separation between ST instances
Especially relevant for:
-
Batch invoices (810)
-
Payment advices (820)
-
Inventory reports (846)
G. Advanced 856 (ASN) hierarchy handling
For 856 documents, the script restructures HL segments into a logical shipment hierarchy:
Shipment
└── Order
└── Pack
└── Item
Benefits
-
Preserves the semantic meaning of HL levels
-
Enables easier mapping to NetSuite Item Fulfillment and Package records
Avoids brittle index-based HL logic
Outbound EDI configurations (Imports in Celigo terminology) are responsible for transforming ERP data into partner-compliant EDI documents. A consistent outbound design approach ensures that integrations remain reusable across trading partners while still allowing for partner-specific customization where required.
When setting up outbound flow step (import):
-
Reuse existing Trading Partner (TP) profiles and File Definition Rules (FDRs) whenever the trading partner is already available as an endpoint connection in Celigo.
-
Avoid duplicating or heavily modifying existing FDRs. Existing outbound definitions are pre-aligned with partner-specific segment ordering, required fields, and validation rules. Reuse enables consistency, reduces errors, and simplifies long-term support and upgrades.
If a trading partner–specific outbound document definition does not exist:
-
Select the generic document definition for the applicable EDI standard (for example, Generic X12 or Generic EDIFACT).
-
Start with a generic definition and introduce partner-specific requirements through mappings or transformation logic rather than creating custom FDRs prematurely. Generic definitions provide a stable, standards-compliant foundation that can be extended through mappings and conditional logic.
Outbound data should be designed to maximize reusability and clarity while allowing flexibility for partner-specific requirements.
Use generic object names
-
Design outbound data using generic object names instead of partner-specific labels.
-
Reuse data across multiple trading partners with minimal changes.
Customize mappings, not flow structure
-
Update field mappings, qualifiers, and conditional logic as needed to meet partner requirements.
-
Avoid changing core flow logic unless absolutely necessary.
Example
-
A generic ShipTo or BillTo object can be mapped differently for each partner without modifying the overall structure.
Validation benefits
Validation helps identify:
-
Missing mandatory segments or elements
-
Invalid qualifiers or code values
-
Structural issues that may cause downstream parsing failures
This phase ensures that the EDI data is broadly aligned with the trading partner’s specifications before go-live.
Before production,
-
Always test using real partner sample files
-
Avoid modifying transformation logic per partner unless unavoidable
-
Document any deviations from generic behavior
-
Keep segment category lists (array-to-object, qualifier-based, etc.) centralized and reusable
EDI validation strategy: For inbound EDI integrations, validation requirements can differ between testing and production phases. Based on implementation experience, a phased approach to EDI validation is recommended.
Before go-live: During testing and certification enable EDI validations in the EDI parser during initial development, partner testing, and certification cycles.Set Skip EDI Validation = False.
EDI validation strategy: For outbound EDI data, always enforce EDI validation to ensure that generated documents fully comply with the trading partner’s specifications.
-
Outbound documents should be validated against trading partners–specific EDI rules, including required segments, segment order, qualifiers, and mandatory data elements.
-
Disabling validation increases the risk of partner rejections, delayed processing, and downstream reconciliation issues.
Before go-live: Always keep EDI validation enabled for outbound flows by ensuring the following setting is applied in the FDRs in the EDI generator helper:
Skip EDI Validation = False
It ensures:
-
Structural compliance with the EDI standard
-
Early detection of missing or invalid data
-
Reduced partner rejections during testing and production
Inbound EDI validation strategy (after go-live)
In production, trading partners may occasionally introduce minor, non-critical deviations (for example, optional segments, unused elements, or formatting inconsistencies) that do not impact business processing but can still trigger validation errors.
These inadvertent validation failures can result in:
-
Unnecessary flow errors
-
Manual intervention by business users
-
Delays in document processing
Disabling validation post go-live allows the integration to remain resilient while still processing business-critical data.
Post go-live: During production steady state after the inbound flow has successfully completed all required testing cycles and is live in production, disable strict EDI validation for inbound documents by setting:
Skip EDI Validation = True
-
Ensure all core business scenarios and edge cases are validated before disabling EDI validation.
-
Monitor inbound documents closely after go-live to confirm that skipped validations do not introduce data quality issues.
-
Re-enable validation temporarily if a major partner-side change is introduced or if systemic data issues are observed.
Note
For outbound flows, the EDI validations should always be turned on to ensure compliance of trading partner’s EDI specifications.
A1. EDI segments
An EDI segment is a logical grouping of data elements that conveys a specific piece of information. Each segment begins with a segment identifier and contains one or more elements in a defined order.
Example: BEG Segment in an 850 Purchase Order
BEG*00*SA*PO12345**20240115~
where
-
BEGrepresents Beginning Segment for Purchase Order -
BEG01(00) represents Transaction Set Purpose Code -
BEG02(SA) represents Purchase Order Type -
BEG03(PO12345) represents Purchase Order Number -
BEG05(20240115) – Purchase Order Date
While the EDI standard defines the BEG segment, trading partners may:
-
Omit optional elements
-
Require specific code values
-
Re-purpose elements based on internal systems
A2. Segment usage
Segment usage refers to how a trading partner actually uses a segment within a transaction, including:
-
Whether the segment is mandatory or optional
-
Which elements within the segment are populated
-
The allowed values for specific elements
-
Maximum number of occurrences
Why segment usage matters
Even if a segment is optional per the standard, a trading partner may:
-
Always require it
-
Reject the document if specific elements are missing
-
Expect data in a different position than documented
Example
REF segment usage
REF*DP*001~
where
-
REF01(DP) represents Reference Identification Qualifier (Department Number) -
REF02(001) represents Department Number
Partner-specific usage
-
ABC Corp may require the REF*DP segment at the header level
-
The specification might list it as optional, but sample files confirm it is mandatory
-
Additional REF segments with different qualifiers (for example, IA, ZZ) may also be required
So, validating sample files is essential before finalizing mappings.
A3. EDI loops
A loop is a repeating group of related segments that represent a logical business entity, such as a line item, address, or party.
Loops allow segments to repeat together in a structured way.
A3.1. Loop Example: Line Item Loop (PO1 Loop) in an 850
The PO1 loop represents individual line items on a purchase order and can repeat multiple times.
Example
PO1*1*10*EA*25.00**BP*ABC123~
PID*F****Product Description~
where
-
Line number: 1
-
Quantity: 10
-
Unit of Measure: EA
-
Unit Price: 25.00
-
Buyer Part Number: ABC123
-
PO1represents Line Item segment -
PIDrepresents Product description associated with the line item
Each PO1 loop represents one item on the order. For an order with multiple items, this loop repeats.
A3.2 Loop Example: Address Loop (N1 Loop)
The N1 loop is used to identify parties such as the buyer, ship-to, or bill-to.
Example
N1*ST*ABC Warehouse~
N3*123 Industrial Way~
N4*Dallas*TX*75201~
where
-
N1*STrepresents Ship-To party -
N3represents Street address -
N4represents City, state, and postal code
This loop may repeat for different parties using different qualifiers:
-
N1*BT – Bill-To
-
N1*SU – Supplier
A4. Segments and loops
-
Validate against sample files, not just specifications
Confirm which segments and loops are actually used, repeated, or required.
-
Confirm maximum occurrences
Some partners restrict how many times a loop (for example, PO1 or N1) can repeat.
-
Watch for partner-specific qualifiers
Qualifier values often drive business logic and routing.
-
Document deviations early.
Any deviation from the standard should be documented and shared with all stakeholders before mapping begins.