Control numbers in X12 EDI

The concept behind control numbers is pretty straightforward, but to work with them in practice, there are a lot of details you need to understand. For example, an interchange control number is a unique identifier for an interchange and you can use it to acknowledge that you received an interchange. In practice, it’s only unique within a certain scope, trading partners may have their own expectations about them regardless of the standard, and it’s uncommon to use them in acknowledgments. And all of that is assuming that you know what an interchange is.

The standard for X12 EDI specifies many things about control numbers, but it may not be as specific as you have come to expect from other standards. Even if it were, not everyone fully adheres to the standard. Don’t fight it; you’ll only get frustrated. Instead, specialize yourself in all the kinks, quirks, and oddities that come with control numbers. The best way to keep your sanity, is to embrace the madness.

Three different control numbers

An EDI message has three different control numbers: the interchange control number, the group control number, and the transaction set control number. Each control number appears twice: once in the opening segment and once in the closing segment.

Interchange, functional group, and transaction set

The interchange tells you who the message is for on the organization level. If you’re working for Exactity and you receive a message from Claritude, then the ISA-segment will identify Claritude as the sender and Exactity as the receiver.

The functional group tells you who the message is for on a department level. If the message from Claritude contains both invoices and ship notices, then one GS-segment will identify your Finance department as the receiver of the invoices and the other GS-segment will identify the Warehouse department as the receiver of the ship notices. In practice, functional groups aren’t always used like this, as we’ll see later.

The transaction set represents a single document. If the Finance department receives three invoices at once, the transaction set control number in the ST-segment will make it easy to keep them apart. This may seem redundant, because invoices already contain an invoice number, but the two numbers serve different purposes. The control number is a technical identifier and it’s only used by the EDI system. The invoice number is an identifier used by the business.

Why we need different control numbers

When you receive a message from your trading partner, you can let them know about it by sending an acknowledgment. One option is to acknowledge each interchange you receive. You send back a message that includes the TA1-segment and you put the interchange control number in there. The TA1-segment also includes a code that lets your trading partner know if there were any problems, but you can’t be all that specific about what went wrong. For example, the TA1-segment has no way to indicate that one of the transaction sets is invalid.

The other option is to acknowledge each functional group you receive, and this gives you more granularity. You send a 997 Functional Acknowledgment for each functional group and include the group control number. You then add information about each transaction set, citing the transaction set control number and including the relevant error information.

But if you can include all that when you acknowledge a functional group, then acknowledging an interchange seems superfluous. That’s true in most cases, but there are two exceptions.

First, the ISA-segment you receive may contain an error. The ISA-segment provides information you need to parse the rest of the EDI message. If there’s a problem with that segment, you’ll never get to the functional groups. The only way to report that, is by using a TA1-segment and include the interchange control number.

Second, you may not process the entire message in the same system. As explained earlier, functional groups allow you to route parts of the message to different departments. If each department uses different software, you may have a setup where all EDI messages come in at a central system that does nothing but route the messages to the correct department. The central system doesn’t look at the transaction sets at all; that’s done by the software of each department individually.

In this setup, each department sends 997s for the transaction sets they are responsible for. The central system can’t do that, because a 997 must include information about transaction sets and the central system doesn’t deal with those. If it encounters an error, the only option is to send a reply with a TA1-segment.

Of course, it’s possible that your situation doesn’t require routing to separate systems and then you’d be happier if you could use group control numbers for everything and forget all about the interchange control number. You can’t, however, because one of your trading partners might need the extra layer of abstraction. Even if you’re sure that’s not the case, this is still how EDI works and you have to deal with it.

Technically correct

The standard for X12 EDI has a fair few things to say about control numbers. Some of these specifications are clear and precise, some are precise but hard to wrap your head around, and some are (intentionally) vague. The result is that you’ll invariably encounter control numbers that don’t adhere to the standard, but before we talk about that, it’s good to know what the standard says.

Data type

The standard is unambiguous when it comes to the data type of the control numbers.

Control numberData typeLengthinterchangeintegerexactly 9groupintegerat most 9transaction setstringat least 4
at most 9

Unambiguous though this may be, it’s still worthy of some examination.

The interchange control number must be exactly nine characters long. The reason for this is that EDI parsers rely on the fact that the ISA-segment has a fixed length. Numbers that don’t meet the minimum length have to be padded with zeros, so interchange control numbers look like 000000014.

The group control number doesn’t have a minimum length. Padding a number with zeros is only appropriate if a number needs to meet a minimum length, so the group control number shouldn’t contain any. At this point, I’d like to remind you that the next section covers ways in which people break the standard.

The transaction set control number is peculiar in two ways. First, it has a minimum length of four, for no apparent reason. Second, it’s a string, not a number. Spaces are valid characters for a string, as are zeros, so technically, the following examples are all valid transaction set control numbers: 1, 0001, 0 1, 1, yolo. Please, don’t stop reading here; we will get back to this.

Uniqueness

Control numbers need to be unique, but only within a certain scope. The standard is specific about this, but it’s easy to get confused by the details.

Control numberUnique with regards tointerchangeISA05 and ISA06 (sender)
ISA07 and ISA08 (receiver)groupGS01 (functional identifier code)
GS02 (sender)
GS03 (receiver)transaction setthe containing functional group

Interchange

Every interchange that Exactity sends to Claritude must have a unique interchange control number. Of course, every interchange that Claritude sends to Exactity must also have a unique interchange control number, but Claritude doesn’t have to take the interchange control numbers it receives from Exactity into account. In other words, if Exactity sends an interchange with control number 000000001 and Claritude sends back an interchange with control number 000000001, then that’s perfectly valid.

The ISA-segment contains identifiers for both the sender (ISA06) and the receiver (ISA08). Question is: who assigns these IDs? The ISA-segment answers that with ID qualifiers: one for the sender (ISA05) and one for the receiver (ISA07). The qualifier tells you what kind of ID you’re dealing with. For example, if the qualifier is 01, then the ID is a DUNS number, but if the qualifier is 20, then the ID is a Health Industry Number. So, the combination of ISA05 and ISA06 identifies the sender and the combination of ISA07 and ISA08 identifies the receiver.

Functional group

The group control number must also be unique within the context of the sender and the receiver, but sender and receiver are defined slightly differently for functional groups than they are for interchanges. The GS-segment doesn’t contain a qualifier that lets you know if you’re dealing with a DUNS number, a Health Industry Number, or whatever other kind of ID, and that makes sense.

Recall that the purpose of the functional group is to route a collection of transaction sets within an organization, for example, send invoices to the Finance department and ship notices to the Warehouse department. Element GS03 identifies the receiver, but in this case, the receiver isn’t Exactity, it’s a department within Exactity. There’s no industry standard for that, so Exactity and Claritude will just have to get to an agreement. However Exactity and Claritude decide to identify the sender (GS02) and the receiver (GS03) in a functional group, is fine as far as the standard is concerned.

There’s another element to the uniqueness of the group control number: GS01. This element contains the functional identifier code, which tells you what type of transaction sets the functional group contains. For example, the code is IN for invoices, or SH for ship notices. So, if Claritude sends Exactity one functional group with invoices and one functional group with ship notices, then they are allowed to have the same group control number. Have I reminded you lately that the upcoming section is going to talk about practical concerns?

Transaction set

The transaction set control number needs to be unique within its functional group. If Claritude sends two invoices, then each invoice must have a unique control number. If Claritude later sends another invoice, then it can reuse a previous control number; the standard doesn’t require that transaction set control numbers are unique across messages.

Recycling control numbers

Since control numbers have a maximum length, there is a possibility that you run out of them. After Claritude has sent a billion interchanges to Exactity, they can’t pick a unique control number for the next interchange anymore and the same thing applies to group control numbers. You may be interested to know that if you send out one interchange per second, it takes well over thirty years before you run out of interchange control numbers. Still, the standard provides a solution for this eventuality.

Well, sort of. It tells you that control numbers need to guarantee uniqueness within a reasonable time frame. It goes on to say that the boundaries of that time frame shall be defined by the trading partner agreement. That’s a fancy way of saying that you and your trading partner need to figure this one out amongst yourselves.

Reality

Knowing the standard is only part of the journey towards understanding control numbers; you’ll have to come to grips with how they are used in reality. Whatever you may think of the practices you find out in the wild, you’ll be happier accepting what comes your way than fighting for what you know to be right.

Sequential control numbers

It’s common for EDI systems to generate control numbers sequentially and consecutively. While the standard doesn’t require it, a lot of trading partners will assume you follow this practice. They’ll expect that after interchange control number 000000001 comes 000000002. If you sent them 000000009 instead, they may contact you about the seven missing interchanges.

The same goes for group control numbers and transaction set control numbers: they don’t have to be sequential, but they often are and some trading partners expect that they are.

The situation gets a bit more complex when your trading partner routes each functional group to a separate department. If the Finance department checks for gaps and the Warehouse department checks for gaps, then a single counter for all the functional groups isn’t sufficient. You need to take the functional group identifier into account and send each department consecutive group control numbers.

Of course, there will also be trading partners that don’t work this way. When you send them group control numbers 1, 2, 3 for invoices and also 1, 2, 3 for ship notices, they’ll complain that you’re sending them duplicate control numbers.

In short, you have to talk to your trading partner about this and understand what they expect.

Numbers and leading zeros

Numbers should only be padded with zeros if those zeros are necessary to meet the minimum length requirement. Despite of this, you’ll see a lot of group control numbers that include leading zeros.

Often, this happens because the trading partner has copied the interchange control number and used it as the group control number. If they never put more than one functional group in an interchange, this makes sense. Why would you generate a separate group control number if you already have a control number that fits all the constraints? Well, all except the leading zeros, but only pedants care about those.

Transaction set control numbers have a minimum length of 4, so the general expectation is that they include leading zeros. Technically, they don’t have to, because they’re not numbers; they’re strings and strings are allowed to have spaces. Practically, most people pretend that transaction set control numbers aren’t strings but numbers, because that just makes more sense, regardless of what the standard says.

Your safest option is to accept leading zeros in the control numbers you receive, and only include them when required for the control numbers you send.

Unique group control numbers

If you recall, group control numbers only need to be unique in the context of the functional identifier code, i.e. the group of invoices can have the same control number as the group of ship notices. Not all EDI systems are implemented this way, though, and the ones that aren’t, need the group of invoices and the group of ship notices to have different control numbers.

This is closely related to the issue about sequential control numbers we discussed previously and the conclusion is the same: you have to discuss this with your trading partner.

Recycling control numbers

There may be a billion unique control numbers in theory, but that doesn’t mean your trading partner will use all of them. Sometimes, a change to their EDI system will prompt them to reset the control number generator. Forget about receiving a message a second for thirty years; you’re getting duplicates right now.

If you can be tolerant of receiving duplicate control numbers, be tolerant. If you can be strict about sending all one billion control numbers before recycling, be strict. In practice, there will be limits to how tolerant you can be and limits to how strict you can be. As the standard says, you and your trading partner need to figure out together what a reasonable time frame is.

Acceptance

Control numbers can be confusing. There are a lot of pesky details and a lot of inconsistencies. Best you can do is to be strict in the control numbers you send and lenient in the control numbers you accept. If that’s not enough, talk to your trading partner, but don’t bother pointing out that technically they’re wrong. Their business has needs, just like yours, and their system has quirks, just like yours. Reality is messy. Just roll with it.