When an exchange between two systems sends only a document number, the same sequence of digits can belong to different documents of different people. The system sees a match and links the records. The error looks like a success.
An illustrative collision
Two registers exchange data, and the matching key is the document number. The records below are invented, but the situation is typical:
| Register | Person | Value in the "number" field | What the document actually is |
|---|---|---|---|
| A | Child, born 2015 | 123456 |
birth certificate, series in another field |
| B | Adult, born 1971 | 123456 |
booklet passport, series in another field |
Both records are correct. But if you match by number alone, the child from register A will be "found" in register B. What happens next depends on what the system does with a match: pulls in an address, checks eligibility for a benefit, counts unique recipients.
A number without a type: a house without a street
A document number is like a house number. Almost every street has a number 12, and without the street name a letter will not arrive. The document type and series play the role of the street.
The analogy has limits: in a city, at least street names do not repeat. Series and numbers of different document types sometimes do overlap, so even the "street" needs clarifying.
Where false matches come from
A matching number is rarely a rare accident. Usually one of four reasons is behind it:
- Separate numbering. Each document type has its own numbering, and six digits easily repeat across types.
- Series in another field. The number was sent, the series was not, or the series sits in a separate field that does not take part in matching.
- Lost leading zeros. The number was stored as a number, and
012345became12345, which is a completely different number. - Look-alike letters. Latin
A,B,Klook like CyrillicА,В,К, but to the system they are different characters.
The first two reasons produce false matches, the last two produce false mismatches: the same person cannot be found in two registers. Either way, the report counts the wrong thing.
Which fields to add to the exchange
A number becomes a reliable key only together with a few fields next to it:
- Document type as a code from a reference list, not free text that everyone writes differently.
- Series as a separate field, if that document type has one.
- Number as a string, without spaces and without converting it to a number.
- Date of issue as an extra check when numbers do coincide.
- Country of issue for foreign documents.
The matching key then becomes type, series and number together, after normalisation (strip spaces, bring Latin and Cyrillic to one alphabet by an agreed rule).
Format checks by type
A "field is not empty" check cannot tell an ID card number from a date typed into the wrong field. Format rules have to depend on the document type. A simplified example for Ukrainian documents:
| Document type | Format rule (simplified) |
|---|---|
| ID card passport | 9 digits |
| Booklet passport | 2 Cyrillic letters and 6 digits |
| Birth certificate | series and 6 digits |
| Foreign document | country of issue required |
Run these rules twice: at data entry and when the data arrives through the exchange. A record that fails should go back to the sender with a reason, not disappear silently or land in the register "as is".
Why this is architecture, not an interface detail
It is tempting to treat this as a detail of a particular API or SOAP service that developers will fix. In fact it is a question of the exchange contract: which fields are mandatory, which reference list the type comes from, who checks the format.
If the contract has a single "document number" field, every receiving system guesses the type its own way. One by length, another by whether there are letters, a third does not guess at all. Fixing this in every report separately is expensive and unreliable. Fixing it once in the contract is cheaper, even if several parties have to agree on the change.
What to do in practice
- Open the exchange specification and check whether the document type is sent as a separate field.
- If not, add the type from a reference list and the series separately from the number.
- Describe format rules for each type and run them at entry and on receipt.
- Match two registers twice: by number only and by the full key. The gap between the results shows the number of false matches.
The last step takes half an hour and gives you an argument that is easy to show to leadership: how many records are matched by mistake right now. That kind of argument is where a conversation about data architecture starts.
And in your case: does the exchange send the document type as a separate field, or does the system still guess it from the length of the number?