Date and time in EDI
May 11, 2022
EDI
The trick to dealing with date and time in an X12 EDI document is to make things easy for yourself. EDI isn’t going to do that for you. EDI makes it possible to put a date on a business document in any way a human being has ever come up with and that flexibility comes at a cost: it’s downright confusing. You don’t have to deal with that confusion, though, because you don’t have to deal with that flexibility. It all starts with the implementation guide that you received from your trading partner.
Implementation guide
The implementation guide tells you what your trading partner expects from you. If your trading partner will send you purchase orders, then the implementation guide will tell you what those purchase orders look like. Every trading partner will format it a bit differently, but it usually looks something like this.
This implementation guide is based on the X12 EDI specification for an 850 Purchase Order. That specification is much broader than you need, though, because it caters for everything anyone could ever want in a purchase order. For example, it contains fields for specifying additional paperwork. Your trading partner doesn’t need that—can’t even handle that—so they send you an implementation guide with only the fields they do expect. In other words, an implementation guide is a subset of the X12 EDI specification and you only have to deal with that subset.
Of course, I don’t know who you’re trading with and I don’t know which type of documents you’re dealing with, so I’ll probably cover a bit more ground here than you need. Just remember: refer to the implementation guide and ignore everything that’s not in there, lest you drive yourself mad.
Segments
If your trading partner sends you a document, you might expect dates to look something like this.
"shippingDate": "2022-04-28T13:05:37Z"However, EDI is different. It looks like this instead.
DTM*11*20220428*130537*UTEvery field is on its own line, except it isn’t called a field; it’s called a segment. Each segment begins with a code that tells you what type of data the segment contains. DTM means that the segment represents a date and time.
EDI actually has three different segments to represent date and time: DTM, DTP, and G62. DTM is the most common, but it’s also the most complicated, so I’ll talk about that one last. Fortunately, everything I’ll show you about G62 and DTP also applies to DTM.
To add to the complexity, date and time are not always expressed with one of these dedicated segments; sometimes they’re embedded into completely different segments. Those segments take bits and pieces of the dedicated date-and-time segments and call them their own.
G62
Date
The G62-segment represents a date like this.
G62*11*20220428The last element of the segment isn’t too hard to understand: it’s the actual date. It’s always in the format YYYYMMDD. There’s also an element in the middle and it isn’t immediately clear what it means. Suppose you have a document for a shipment status update that contains two different dates.
"shippedDate": "2022-04-28"
"estimatedDeliveryDate": "2022-04-29"In EDI, that would look like this.
G62*11*20220428
G62*17*20220429EDI doesn’t have named fields. Instead it uses a code. 11 stand for Shipped on This Date and 17 stands for Estimated Delivery Date. If you take a look at the full list of possible codes, you’ll see that there are 137 of them. That’s a lot. They all have names, but those don’t do a good job of explaining what they mean. That’s when you turn to the implementation guide your trading partner gave you.
As you can see, your trading partner will only ever send you an 11 or a 17. That makes sense, because a code like BC - Publication Date doesn’t mean anything in the context of a shipment status update.
Time
The G62 example I gave only shows a date, but a G62 can contain a time as well. In fact, the full specification of a G62 looks like this.
Again, the implementation guide will tell you whether you need the full segment, but since we’ve already seen an example of a date, let’s take a look at an example of a time.
G62***8*1547*LTThe elements with information about a date are left empty. The delimiter * is still there, otherwise we wouldn’t know how many fields we skipped. So, that’s what those three stars between G62 and 8 mean: skip the two date fields.
1547 is the time: 3:47 PM. It’s always specified in a 24-hour clock. The example shows the shortest time format possible, but times can also have seconds and even fractions of seconds.
FormatExampleMeaningHHMM09059:05 AMHHMMSS1928517:28:51 PMHHMMSSD104537810:45:37.8 AMHHMMSSDD2307429111:07:42.91 PM
If you want to be sure which format you need to handle, you’ll have to check the implementation guide.
The 8 in the example is a code for the kind of time you’re dealing with, just like 11 and 17 were codes for the kind of date. 8 means Actual Pickup Time. You could look up all the possible codes, but it’s better to refer to your implementation guide.
The last element specifies the time zone. When you look up the time zone codes, some of the descriptions can be a bit confusing, but there’s method to the madness. Equivalent to ISO P08 means UTC+08 and Equivalent to ISO M03 means UTC-03. In other words, the number at the end is the offset from UTC where P means + and M means -.
In the example, the time zone is LT, which means Local Time. It depends on the context which time zone that is. If you’re dealing with a shipment status update, then it stands to reason that the local time for the pickup is local to wherever the pickup occurred.
Date-time
Since G62 can represent both a date and a time, it can also represent a date-time.
G62*11*20220428*8*1547*LTThis segment tells you that the package shipped on April 28, 2022 at 3:47 PM local time. It’s actually unlikely that you will get both a date qualifier (11) and a time qualifier (8) in the same segment, since they convey similar information, but check your implementation guide to be sure.
DTP
The DTP-segment is also used to express dates and times, but it’s more flexible than the G62-segment. DTP can express almost everything G62 can—except for time zones and fractions of seconds—and it has some extra features on top.
Date
A simple date looks like this.
DTP*11*D8*20220428As you can see, the date is at the end. The first element is the same as with the G62: it tells you what kind of date you’re dealing with. The value 11 means Shipped, so that’s the same as with the G62, even if it’s describes slightly differently. The entire list of possible codes for the DTP is much longer, though; more than a thousand possibilities. Definitely check your implementation guide to see which ones are relevant to you.
The element in the middle is new. It specifies the format to use. D8 means that this is a date in YYYYMMDD format. This is where DTP becomes more flexible than G62: you can use different formats. For example, D6 means a date in YYMMDD format, TT means a date in MMDDYY format, and CY means a date expressed as a year and a quarter, e.g. 20221 means Q1 of 2022. That last one is interesting, because there’s no way to express the concept of a quarter in a regular date format. There’s even the notion of a Julian date, which just numbers days consecutively, starting on January 1st and it’s particularly fun to deal with in leap years. I imagine Julian dates are rare, but hey, if you need it, you need it.
Time
DTP can do time as well.
DTP*11*TM*1547TM means a time in HHMM format and, as with G62, DTP always uses a 24-hour clock. Another code is TS, which means a time in HHMMSS format. There’s no code that allows you to specify fractions of a seconds, so that’s a feature of G62 that DTP doesn’t have. DTP also doesn’t provide a way to specify a time zone.
Date-time
Expressing a date-time doesn’t require any extra fields, just a different format qualifier.
DTP*11*DT*202204281547As you may expect, DT means a date-time in YYYYMMDDHHMM format and the date-time in the example is April 28, 2022 at 3:47 PM. If the qualifier is set to RTS instead of DT, the date-time will include seconds as well.
Range
Where DTP truly trumps G62, is in its ability to represent date ranges.
DTP*135*RD8*20211224-20220104This represents December 24, 2021 to January 4, 2022. As before, the qualifier gives the exact format and RD8 means a date range in YYYYMMDD-YYYMMDD format. There are also ranges that include a time, and ranges that use only years, and everything in between. You can check out the full list of qualifiers, but it’s even better to check your trading partner’s implementation guide.
DTM
The DTM-segment is the most common way of representing date and time in EDI. It’s also the most flexible, because it has the capabilities of both the G62-element and the DTP-element. That would also make it the most confusing, except that you’ve already seen G62 and DTP, so there’s nothing left to say about DTM.
As you can see, it’s just a combination of the G62-elements and the DTP-elements. You do need to figure out which of these elements are used and which are ignored, but by now, you know how to do that as well: check the implementation guide.
Other segments
If you have to deal with an 850 Purchase Order, you’ll find that it contains a segment called BEG and that segment has an element to represent a date. It’s the same element as you find in a G62 or a DTM—a date expressed in YYYYMMDD format—just embedded in a segment that otherwise has nothing to do with dates. In the case of a purchase order, it represents the date of the purchase order as defined by the purchaser.
It’s not limited to the BEG-segment, though. For example, the B10-segment includes both a date and a time. The AT7-segment includes date, time and time code, and the CUR-segment has a date and time plus a date/time qualifier. And there are many, many more segments like this. It’s a lot to handle, but there’s a saving grace: they all use a combination of the elements described in this article, so by now, you should be well equipped to deal with them.
The trick to dealing with date and time in an X12 EDI document is to make things easy for yourself. EDI isn’t going to do that for you. EDI makes it possible to put a date on a business document in any way a human being has ever come up with and that flexibility comes at a cost: it’s downright confusing. You don’t have to deal with that confusion, though, because you don’t have to deal with that flexibility. It all starts with the implementation guide that you received from your trading partner.
Implementation guide
The implementation guide tells you what your trading partner expects from you. If your trading partner will send you purchase orders, then the implementation guide will tell you what those purchase orders look like. Every trading partner will format it a bit differently, but it usually looks something like this.
This implementation guide is based on the X12 EDI specification for an 850 Purchase Order. That specification is much broader than you need, though, because it caters for everything anyone could ever want in a purchase order. For example, it contains fields for specifying additional paperwork. Your trading partner doesn’t need that—can’t even handle that—so they send you an implementation guide with only the fields they do expect. In other words, an implementation guide is a subset of the X12 EDI specification and you only have to deal with that subset.
Of course, I don’t know who you’re trading with and I don’t know which type of documents you’re dealing with, so I’ll probably cover a bit more ground here than you need. Just remember: refer to the implementation guide and ignore everything that’s not in there, lest you drive yourself mad.
Segments
If your trading partner sends you a document, you might expect dates to look something like this.
"shippingDate": "2022-04-28T13:05:37Z"However, EDI is different. It looks like this instead.
DTM*11*20220428*130537*UTEvery field is on its own line, except it isn’t called a field; it’s called a segment. Each segment begins with a code that tells you what type of data the segment contains. DTM means that the segment represents a date and time.
EDI actually has three different segments to represent date and time: DTM, DTP, and G62. DTM is the most common, but it’s also the most complicated, so I’ll talk about that one last. Fortunately, everything I’ll show you about G62 and DTP also applies to DTM.
To add to the complexity, date and time are not always expressed with one of these dedicated segments; sometimes they’re embedded into completely different segments. Those segments take bits and pieces of the dedicated date-and-time segments and call them their own.
G62
Date
The G62-segment represents a date like this.
G62*11*20220428The last element of the segment isn’t too hard to understand: it’s the actual date. It’s always in the format YYYYMMDD. There’s also an element in the middle and it isn’t immediately clear what it means. Suppose you have a document for a shipment status update that contains two different dates.
"shippedDate": "2022-04-28"
"estimatedDeliveryDate": "2022-04-29"In EDI, that would look like this.
G62*11*20220428
G62*17*20220429EDI doesn’t have named fields. Instead it uses a code. 11 stand for Shipped on This Date and 17 stands for Estimated Delivery Date. If you take a look at the full list of possible codes, you’ll see that there are 137 of them. That’s a lot. They all have names, but those don’t do a good job of explaining what they mean. That’s when you turn to the implementation guide your trading partner gave you.
As you can see, your trading partner will only ever send you an 11 or a 17. That makes sense, because a code like BC - Publication Date doesn’t mean anything in the context of a shipment status update.
Time
The G62 example I gave only shows a date, but a G62 can contain a time as well. In fact, the full specification of a G62 looks like this.
Again, the implementation guide will tell you whether you need the full segment, but since we’ve already seen an example of a date, let’s take a look at an example of a time.
G62***8*1547*LTThe elements with information about a date are left empty. The delimiter * is still there, otherwise we wouldn’t know how many fields we skipped. So, that’s what those three stars between G62 and 8 mean: skip the two date fields.
1547 is the time: 3:47 PM. It’s always specified in a 24-hour clock. The example shows the shortest time format possible, but times can also have seconds and even fractions of seconds.
FormatExampleMeaningHHMM09059:05 AMHHMMSS1928517:28:51 PMHHMMSSD104537810:45:37.8 AMHHMMSSDD2307429111:07:42.91 PM
If you want to be sure which format you need to handle, you’ll have to check the implementation guide.
The 8 in the example is a code for the kind of time you’re dealing with, just like 11 and 17 were codes for the kind of date. 8 means Actual Pickup Time. You could look up all the possible codes, but it’s better to refer to your implementation guide.
The last element specifies the time zone. When you look up the time zone codes, some of the descriptions can be a bit confusing, but there’s method to the madness. Equivalent to ISO P08 means UTC+08 and Equivalent to ISO M03 means UTC-03. In other words, the number at the end is the offset from UTC where P means + and M means -.
In the example, the time zone is LT, which means Local Time. It depends on the context which time zone that is. If you’re dealing with a shipment status update, then it stands to reason that the local time for the pickup is local to wherever the pickup occurred.
Date-time
Since G62 can represent both a date and a time, it can also represent a date-time.
G62*11*20220428*8*1547*LTThis segment tells you that the package shipped on April 28, 2022 at 3:47 PM local time. It’s actually unlikely that you will get both a date qualifier (11) and a time qualifier (8) in the same segment, since they convey similar information, but check your implementation guide to be sure.
DTP
The DTP-segment is also used to express dates and times, but it’s more flexible than the G62-segment. DTP can express almost everything G62 can—except for time zones and fractions of seconds—and it has some extra features on top.
Date
A simple date looks like this.
DTP*11*D8*20220428As you can see, the date is at the end. The first element is the same as with the G62: it tells you what kind of date you’re dealing with. The value 11 means Shipped, so that’s the same as with the G62, even if it’s describes slightly differently. The entire list of possible codes for the DTP is much longer, though; more than a thousand possibilities. Definitely check your implementation guide to see which ones are relevant to you.
The element in the middle is new. It specifies the format to use. D8 means that this is a date in YYYYMMDD format. This is where DTP becomes more flexible than G62: you can use different formats. For example, D6 means a date in YYMMDD format, TT means a date in MMDDYY format, and CY means a date expressed as a year and a quarter, e.g. 20221 means Q1 of 2022. That last one is interesting, because there’s no way to express the concept of a quarter in a regular date format. There’s even the notion of a Julian date, which just numbers days consecutively, starting on January 1st and it’s particularly fun to deal with in leap years. I imagine Julian dates are rare, but hey, if you need it, you need it.
Time
DTP can do time as well.
DTP*11*TM*1547TM means a time in HHMM format and, as with G62, DTP always uses a 24-hour clock. Another code is TS, which means a time in HHMMSS format. There’s no code that allows you to specify fractions of a seconds, so that’s a feature of G62 that DTP doesn’t have. DTP also doesn’t provide a way to specify a time zone.
Date-time
Expressing a date-time doesn’t require any extra fields, just a different format qualifier.
DTP*11*DT*202204281547As you may expect, DT means a date-time in YYYYMMDDHHMM format and the date-time in the example is April 28, 2022 at 3:47 PM. If the qualifier is set to RTS instead of DT, the date-time will include seconds as well.
Range
Where DTP truly trumps G62, is in its ability to represent date ranges.
DTP*135*RD8*20211224-20220104This represents December 24, 2021 to January 4, 2022. As before, the qualifier gives the exact format and RD8 means a date range in YYYYMMDD-YYYMMDD format. There are also ranges that include a time, and ranges that use only years, and everything in between. You can check out the full list of qualifiers, but it’s even better to check your trading partner’s implementation guide.
DTM
The DTM-segment is the most common way of representing date and time in EDI. It’s also the most flexible, because it has the capabilities of both the G62-element and the DTP-element. That would also make it the most confusing, except that you’ve already seen G62 and DTP, so there’s nothing left to say about DTM.
As you can see, it’s just a combination of the G62-elements and the DTP-elements. You do need to figure out which of these elements are used and which are ignored, but by now, you know how to do that as well: check the implementation guide.
Other segments
If you have to deal with an 850 Purchase Order, you’ll find that it contains a segment called BEG and that segment has an element to represent a date. It’s the same element as you find in a G62 or a DTM—a date expressed in YYYYMMDD format—just embedded in a segment that otherwise has nothing to do with dates. In the case of a purchase order, it represents the date of the purchase order as defined by the purchaser.
It’s not limited to the BEG-segment, though. For example, the B10-segment includes both a date and a time. The AT7-segment includes date, time and time code, and the CUR-segment has a date and time plus a date/time qualifier. And there are many, many more segments like this. It’s a lot to handle, but there’s a saving grace: they all use a combination of the elements described in this article, so by now, you should be well equipped to deal with them.
The trick to dealing with date and time in an X12 EDI document is to make things easy for yourself. EDI isn’t going to do that for you. EDI makes it possible to put a date on a business document in any way a human being has ever come up with and that flexibility comes at a cost: it’s downright confusing. You don’t have to deal with that confusion, though, because you don’t have to deal with that flexibility. It all starts with the implementation guide that you received from your trading partner.
Implementation guide
The implementation guide tells you what your trading partner expects from you. If your trading partner will send you purchase orders, then the implementation guide will tell you what those purchase orders look like. Every trading partner will format it a bit differently, but it usually looks something like this.
This implementation guide is based on the X12 EDI specification for an 850 Purchase Order. That specification is much broader than you need, though, because it caters for everything anyone could ever want in a purchase order. For example, it contains fields for specifying additional paperwork. Your trading partner doesn’t need that—can’t even handle that—so they send you an implementation guide with only the fields they do expect. In other words, an implementation guide is a subset of the X12 EDI specification and you only have to deal with that subset.
Of course, I don’t know who you’re trading with and I don’t know which type of documents you’re dealing with, so I’ll probably cover a bit more ground here than you need. Just remember: refer to the implementation guide and ignore everything that’s not in there, lest you drive yourself mad.
Segments
If your trading partner sends you a document, you might expect dates to look something like this.
"shippingDate": "2022-04-28T13:05:37Z"However, EDI is different. It looks like this instead.
DTM*11*20220428*130537*UTEvery field is on its own line, except it isn’t called a field; it’s called a segment. Each segment begins with a code that tells you what type of data the segment contains. DTM means that the segment represents a date and time.
EDI actually has three different segments to represent date and time: DTM, DTP, and G62. DTM is the most common, but it’s also the most complicated, so I’ll talk about that one last. Fortunately, everything I’ll show you about G62 and DTP also applies to DTM.
To add to the complexity, date and time are not always expressed with one of these dedicated segments; sometimes they’re embedded into completely different segments. Those segments take bits and pieces of the dedicated date-and-time segments and call them their own.
G62
Date
The G62-segment represents a date like this.
G62*11*20220428The last element of the segment isn’t too hard to understand: it’s the actual date. It’s always in the format YYYYMMDD. There’s also an element in the middle and it isn’t immediately clear what it means. Suppose you have a document for a shipment status update that contains two different dates.
"shippedDate": "2022-04-28"
"estimatedDeliveryDate": "2022-04-29"In EDI, that would look like this.
G62*11*20220428
G62*17*20220429EDI doesn’t have named fields. Instead it uses a code. 11 stand for Shipped on This Date and 17 stands for Estimated Delivery Date. If you take a look at the full list of possible codes, you’ll see that there are 137 of them. That’s a lot. They all have names, but those don’t do a good job of explaining what they mean. That’s when you turn to the implementation guide your trading partner gave you.
As you can see, your trading partner will only ever send you an 11 or a 17. That makes sense, because a code like BC - Publication Date doesn’t mean anything in the context of a shipment status update.
Time
The G62 example I gave only shows a date, but a G62 can contain a time as well. In fact, the full specification of a G62 looks like this.
Again, the implementation guide will tell you whether you need the full segment, but since we’ve already seen an example of a date, let’s take a look at an example of a time.
G62***8*1547*LTThe elements with information about a date are left empty. The delimiter * is still there, otherwise we wouldn’t know how many fields we skipped. So, that’s what those three stars between G62 and 8 mean: skip the two date fields.
1547 is the time: 3:47 PM. It’s always specified in a 24-hour clock. The example shows the shortest time format possible, but times can also have seconds and even fractions of seconds.
FormatExampleMeaningHHMM09059:05 AMHHMMSS1928517:28:51 PMHHMMSSD104537810:45:37.8 AMHHMMSSDD2307429111:07:42.91 PM
If you want to be sure which format you need to handle, you’ll have to check the implementation guide.
The 8 in the example is a code for the kind of time you’re dealing with, just like 11 and 17 were codes for the kind of date. 8 means Actual Pickup Time. You could look up all the possible codes, but it’s better to refer to your implementation guide.
The last element specifies the time zone. When you look up the time zone codes, some of the descriptions can be a bit confusing, but there’s method to the madness. Equivalent to ISO P08 means UTC+08 and Equivalent to ISO M03 means UTC-03. In other words, the number at the end is the offset from UTC where P means + and M means -.
In the example, the time zone is LT, which means Local Time. It depends on the context which time zone that is. If you’re dealing with a shipment status update, then it stands to reason that the local time for the pickup is local to wherever the pickup occurred.
Date-time
Since G62 can represent both a date and a time, it can also represent a date-time.
G62*11*20220428*8*1547*LTThis segment tells you that the package shipped on April 28, 2022 at 3:47 PM local time. It’s actually unlikely that you will get both a date qualifier (11) and a time qualifier (8) in the same segment, since they convey similar information, but check your implementation guide to be sure.
DTP
The DTP-segment is also used to express dates and times, but it’s more flexible than the G62-segment. DTP can express almost everything G62 can—except for time zones and fractions of seconds—and it has some extra features on top.
Date
A simple date looks like this.
DTP*11*D8*20220428As you can see, the date is at the end. The first element is the same as with the G62: it tells you what kind of date you’re dealing with. The value 11 means Shipped, so that’s the same as with the G62, even if it’s describes slightly differently. The entire list of possible codes for the DTP is much longer, though; more than a thousand possibilities. Definitely check your implementation guide to see which ones are relevant to you.
The element in the middle is new. It specifies the format to use. D8 means that this is a date in YYYYMMDD format. This is where DTP becomes more flexible than G62: you can use different formats. For example, D6 means a date in YYMMDD format, TT means a date in MMDDYY format, and CY means a date expressed as a year and a quarter, e.g. 20221 means Q1 of 2022. That last one is interesting, because there’s no way to express the concept of a quarter in a regular date format. There’s even the notion of a Julian date, which just numbers days consecutively, starting on January 1st and it’s particularly fun to deal with in leap years. I imagine Julian dates are rare, but hey, if you need it, you need it.
Time
DTP can do time as well.
DTP*11*TM*1547TM means a time in HHMM format and, as with G62, DTP always uses a 24-hour clock. Another code is TS, which means a time in HHMMSS format. There’s no code that allows you to specify fractions of a seconds, so that’s a feature of G62 that DTP doesn’t have. DTP also doesn’t provide a way to specify a time zone.
Date-time
Expressing a date-time doesn’t require any extra fields, just a different format qualifier.
DTP*11*DT*202204281547As you may expect, DT means a date-time in YYYYMMDDHHMM format and the date-time in the example is April 28, 2022 at 3:47 PM. If the qualifier is set to RTS instead of DT, the date-time will include seconds as well.
Range
Where DTP truly trumps G62, is in its ability to represent date ranges.
DTP*135*RD8*20211224-20220104This represents December 24, 2021 to January 4, 2022. As before, the qualifier gives the exact format and RD8 means a date range in YYYYMMDD-YYYMMDD format. There are also ranges that include a time, and ranges that use only years, and everything in between. You can check out the full list of qualifiers, but it’s even better to check your trading partner’s implementation guide.
DTM
The DTM-segment is the most common way of representing date and time in EDI. It’s also the most flexible, because it has the capabilities of both the G62-element and the DTP-element. That would also make it the most confusing, except that you’ve already seen G62 and DTP, so there’s nothing left to say about DTM.
As you can see, it’s just a combination of the G62-elements and the DTP-elements. You do need to figure out which of these elements are used and which are ignored, but by now, you know how to do that as well: check the implementation guide.
Other segments
If you have to deal with an 850 Purchase Order, you’ll find that it contains a segment called BEG and that segment has an element to represent a date. It’s the same element as you find in a G62 or a DTM—a date expressed in YYYYMMDD format—just embedded in a segment that otherwise has nothing to do with dates. In the case of a purchase order, it represents the date of the purchase order as defined by the purchaser.
It’s not limited to the BEG-segment, though. For example, the B10-segment includes both a date and a time. The AT7-segment includes date, time and time code, and the CUR-segment has a date and time plus a date/time qualifier. And there are many, many more segments like this. It’s a lot to handle, but there’s a saving grace: they all use a combination of the elements described in this article, so by now, you should be well equipped to deal with them.
Share
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.
Backed by
Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.