How do you check a move in both directions?

A move is checked in both directions by reading the correspondence table from NACE Rev. 2 to NACE Rev. 2.1, and then from NACE Rev. 2.1 to NACE Rev. 2, stating the direction for each reading. The Eurostat manual states that complete detailed correspondences between NACE Rev. 2 and NACE Rev. 2.1, and vice versa, are available online. A type quoted without a direction is incomplete, and may be the reverse of the type needed.

How do the types reverse?

A many to many correspondence is symmetric as a group: the joint scope of the old set is identical to the joint scope of the new set, in both directions. The individual classes inside the group have no pairing in either direction, so the reverse reading does not create pairings that the forward reading lacked. A reader who checks a many to many group in the reverse direction will find the same group, with the sides swapped, and the same warning applies: the group must be treated as a whole, and no individual pairing must be inferred. The symmetry of the group does not make the individual rows symmetric, because there are no individual rows inside the group in the sense of pairings.

Forward direction, Rev. 2 to Rev. 2.1	Reverse direction, Rev. 2.1 to Rev. 2
1 to 1, exact correspondence	1 to 1, exact correspondence
n to 1, merger	1 to n, split when read backwards
1 to m, split	m to 1, merger when read backwards
n to m, joint scope identity	m to n, joint scope identity, group as a whole

What is checked in each direction?

In the forward direction, the check starts with an old class and asks which new classes cover its scope. The table row or group for the old class lists the new classes, with the type. The notes for the new classes, and the old note, are then compared, to see how the old scope was divided, combined, or preserved. In the reverse direction, the check starts with a new class and asks which old classes supplied its scope. The table row or group for the new class lists the old classes, with the type in the reverse direction. The notes for the old classes, and the new note, are then compared, to see how the new scope was formed.

The two checks can give different impressions if only one is done, because the starting point changes what is visible. A forward check from a merged old class will show the new class that covers it, together with the other old classes that were merged into the same new class. A reverse check from the new class will show all the old classes that were merged, as a set. Both checks describe the same merger, but the reverse check makes the set visible at once, while the forward check makes it visible only by following each old class in turn. A complete check therefore does both, and states the set in full, in both directions, before drawing a conclusion about the scope.

The verified agriculture merger illustrates the two directions with real codes. Forward, classes 01.63 and 01.64 in NACE Rev. 2 merge into class 01.63 in NACE Rev. 2.1, a many to one relationship. Reverse, class 01.63 in NACE Rev. 2.1 splits, when read backwards, into classes 01.63 and 01.64 in NACE Rev. 2, a one to many relationship in the reverse direction. The codes overlap, because the new class reuses an old code, and the direction is essential to avoid confusion: the same code 01.63 denotes a narrower scope in the old version and a broader, combined scope in the new version, and only the direction and the version label distinguish the two uses.

Why must the table version be checked in both directions?

The version check also applies to the notes. The notes for the old version and the notes for the new version belong to different publications, and the index for the new version is designed to evolve and be regularly revised, according to the manual. A note quoted from the manual for the new version must be checked against the current note on ShowVoc, where the index has been revised, and a difference must be noted. A correspondence check that uses an old note with a new table, or a new note with an old table, mixes versions, and the mixed reading must not be presented as a verified move.

What does a two direction check not do?

A two direction check does not assign a code, and it does not confirm an entry. It verifies a category relationship in both directions, so that the relationship can be stated completely and without direction confusion. The assignment of a unit, and the confirmation of an entry, remain separate steps, made by the institute or register that holds the record, using the notes and the rules. A reader who has checked a move in both directions has verified the relationship. That reader must still read the notes for the scope, and must still confirm an entry with the institute or register, before presenting a code as the code for a specific business or activity.

State the direction for each reading, note the table version for both directions, and confirm any entry with the national statistical institute or the business register that holds the record.