Free tool / no upload
Credential file reconciliation: match production and backend UID lists
Load the production personalization file on one side and the backend export on the other. The engine matches identifiers across representations and byte orders, then hands you the exception register and a corrected import file.
MATCH / 2× CSV
Credential file reconciliation
Compare a production personalization file with a backend export. The engine recognizes normalized, padded, decimal-equivalent and reversed-byte identifiers.
Production file
Issued or personalized credential records
Backend file
Imported or registered credential records
Load both files to begin reconciliation.
The classic failure this prevents
Cards arrive, the batch is imported, and a share of them is rejected at the charge point or reader. The chips are almost always fine: the production file and the backend simply describe the same identifiers differently. One side stores hexadecimal, the other decimal; one keeps leading zeros, the other dropped them; somewhere in the chain the byte order was reversed.
Debugging this by eye across thousands of rows is slow and error-prone. Reconciling the two files before or immediately after delivery turns a week of support tickets into a five-minute check.
How the matching engine works
Every identifier from both files is normalized to a canonical byte sequence at the selected length. The engine then matches records in four passes: exact or normalized matches, leading-zero-padded matches, decimal-equivalent matches, and reversed-byte-order matches. Each match is labeled with its category so you can see how the mismatch happened.
What remains is the exception register: identifiers missing in the backend, extras in the backend, duplicates on either side, ambiguous cases with several candidates, and values that could not be interpreted at the chosen length.
Exports that end the argument
Three CSV exports come out of a reconciliation run: the exception register for whoever owns the data, the match evidence linking every production record to its backend record, and a corrected import file already converted to the representation and byte order the backend expects.
Both files are parsed locally in your browser and never uploaded. For future orders, the companion data contract tool captures the agreed format as JSON with acceptance vectors, so the next batch imports cleanly the first time.
Reconciliation questions
Reconciliation questions
The most common causes are representation and byte-order mismatches: the backend stores decimal while the file was hexadecimal, leading zeros were lost, or the reader path reverses bytes. Reconcile the production file against the backend export to see exactly which transformation explains the mismatch.
First confirm the reversal by reconciling both files: reversed matches are labeled explicitly. Then correct one side only, ideally by re-importing a corrected file in the backend's expected byte order. Avoid fixing individual records by hand across thousands of rows.
A short machine-readable agreement that fixes identifier byte length, representation, byte order, leading-zero policy and letter case between card producer and backend operator, together with acceptance vectors to test against. It removes the ambiguity that causes reconciliation exceptions.
No. Both files are parsed and matched locally in your browser. Nothing is transmitted to or stored by ChargeRFID, so the tool can be used with production credential data.
Related tools
Make the next delivery import cleanly the first time.
Every ChargeRFID order ships with a machine-readable data contract and acceptance vectors agreed before production, so reconciliation becomes a formality instead of a rescue.