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.

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

Why we need different control numbers

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.

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

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.

Interchange

Functional group

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.

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

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.

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