What Is the Modbus Transaction Identifier?
The transaction identifier is the two-byte field at the front of every Modbus TCP message that lets a master pair each response with the request that produced it. It is what makes it safe to have several requests outstanding on one connection. This reference explains what the transaction identifier does, why it matters for anything beyond one-request-at-a-time polling, and the bugs that appear when it is ignored.
Modbus Transaction Identifier in one line: The Modbus transaction identifier is a two-byte value the master puts in the MBAP header of each request; the device copies it unchanged into the response. It lets the master match a reply to the specific request that caused it, so several requests can be in flight on one TCP connection at once. Ignoring it and assuming replies arrive in order is a common source of mismatched data.
What the Transaction Identifier Does
On Modbus TCP a master can send more than one request before the first reply arrives, which is efficient on a network with any latency. But that raises a problem: when several replies come back, which reply answers which request? The transaction identifier solves it. The master chooses a value for each request and the device echoes that exact value in the corresponding response, so the master can pair them unambiguously regardless of the order they arrive. It is one of the four fields of the MBAP header detailed in the Modbus MBAP header reference.
This matters only on TCP. Serial Modbus is strictly request-then-reply on a shared wire, so there is never more than one exchange in progress and no need to label it. The transaction identifier is therefore specific to the TCP transport, one of the differences highlighted in the Modbus TCP vs RTU comparison.
Bugs That Appear When It Is Ignored
A master that ignores the transaction identifier and simply assumes the next reply answers the last request it sent will work fine as long as it only ever has one request outstanding. The moment it pipelines, or the moment replies arrive out of order, it will attribute a reply to the wrong request and silently store the wrong value against the wrong tag. This class of bug is insidious because nothing errors; the data is just quietly wrong, which is far harder to catch than a timeout, a symptom family discussed in the Modbus serial response delay reference.
The correct behavior is to verify that a reply's transaction identifier matches the request being answered and to discard or requeue anything that does not line up. A related pitfall is a device or gateway that does not echo the transaction identifier correctly, which breaks matching for a compliant master; when a TCP master reads plausible but wrong values under load, mismatched transaction identifiers are worth checking alongside the unit-identifier confusion described in the Modbus unit ID and slave address reference.
Frequently Asked Questions
What is the Modbus transaction identifier used for?
It lets a Modbus TCP master match each response to the request that produced it. The master puts a two-byte value in each request's MBAP header and the device echoes it in the reply, so several requests can be outstanding on one connection at once and their replies paired correctly regardless of arrival order.
Does serial Modbus have a transaction identifier?
No. Serial RTU and ASCII are strictly request-then-reply on a shared wire, with only one exchange in progress at a time, so there is nothing to label. The transaction identifier is a Modbus TCP feature, part of the MBAP header, and exists precisely because TCP allows multiple requests to be in flight.
What goes wrong if a master ignores the transaction identifier?
As long as only one request is outstanding, nothing. But once the master pipelines requests or replies arrive out of order, it can attribute a response to the wrong request and store the wrong value against a tag with no error raised. Matching the transaction identifier on every reply prevents this silent data corruption.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.