SHA-256 turns a file’s bytes into a 64-character hexadecimal fingerprint. The same file yields the same fingerprint; even a tiny difference almost certainly yields another. This verifies that exported XML matches the copy sealed at issue. The hash alone does not name an author, provide a legally reliable time or prove DGI filing.
Read the hash correctly
- SHA-256 calculates a deterministic fingerprint over exact bytes.
- Changing one letter, space or encoding changes the result.
- A match establishes identical bytes, not commercial truth.
- A hash alone is not an electronic signature, qualified seal or trusted timestamp.
- Keep the reference in a separate manifest and test before transmission and after restore.
- BelloPOS seals issued UBL locally and re-exports that exact copy.
1. How MAD 1,200 becomes a fingerprint
The algorithm understands neither invoices nor dirhams. It reads XML tags, letters, digits, spaces and line endings as bytes and always produces 256 bits, commonly displayed as 64 characters. A small invoice and large ZIP have equal-length hashes. Understand the content first with the UBL 2.1 guide.
| Action on a copy | Expected hash | Meaning |
|---|---|---|
| No change | Same | Compared bytes are identical |
| 1,200.00 becomes 1,201.00 | Different | Content changed |
| Add a space | Different | Binary representation changed |
| New encoding or line endings | Different | Text may look alike, bytes do not |
| Rename only | Same | Filename is outside file-content hash |
| Create a new ZIP | Different ZIP hash | The archive is another object |
The avalanche effect gives visually unrelated hashes after a tiny change. Hashes do not show which field changed; they tell you the bytes differ, after which you compare files or return to source.
2. What the fingerprint really proves
Given a separately retained reference, a matching current calculation establishes that the tested file has the same bytes. BelloPOS calculates its reference when the invoice receives its number and stores XML locally. The XML and ZIP export manifest repeats it for reconciliation.
- Integrity: Detect that a file no longer matches its reference copy.
- Deduplication: Recognize byte-identical copies despite different names.
- Hand-off: Record what was sent and verify what arrived.
- Restore: Check that a backup returned the expected object exactly.
- Trail: Connect a manifest number to corresponding XML.
Evidence depends on protecting the reference. If an attacker changes both XML and the hash stored beside it, naive comparison detects nothing. Copy the manifest or journal into a protected location, restrict rights and maintain several backups.
3. What SHA-256 does not prove
A hash is an integrity tool, not a universal legal conclusion.
| Question | Does SHA-256 answer? | Additional evidence |
|---|---|---|
| Who issued it? | No | Identity, permissions, log and perhaps signature |
| When did it exist? | No | Protected log or trusted timestamp |
| Is VAT correct? | No | Tax rules and accounting review |
| Did customer receive it? | No | Delivery receipt |
| Did DGI accept it? | No | Official channel response |
| Did the file change? | Yes, with reliable reference | Full recalculation and comparison |
Do not call a hashed file signed. An electronic signature connects data to a signer and verification mechanism; an electronic seal and timestamp have other roles. The stamp, signature and seal guide compares them.
A fingerprint is not tax validation
SHA-256 in a BelloPOS manifest documents the application’s technical choice and enables local verification. It is not a DGI token, public-official signature, software approval or filing receipt.
4. Practical test on a copy
Export XML, calculate SHA-256 with a trusted local tool and record the result. Duplicate the file, change one character in the copy and calculate again. The strings must differ. Delete the altered copy, not the sealed original.
Windows Get-FileHash supports SHA256. macOS and Linux commonly use shasum -a 256. Verify the exact path and compare all 64 characters; a screenshot of a few characters is insufficient for an evidence log.
Repeat after copying to media, restoring a backup or accountant receipt. A mismatch does not automatically mean fraud: incomplete transfer, text rewriting, changed line endings or wrong file may explain it. Stop the flow until identified.
5. Sealing inside BelloPOS
When a covered invoice or credit note is issued, BelloPOS builds UBL 2.1, hashes its UTF-8 string and stores XML, hash, number, type, state and local seal time in the outbox. The operation is idempotent: reprinting must not create a second seal.
| Moment | Object | Result |
|---|---|---|
| Issue | Exact UBL XML | Hash and local copy |
| Reprint | Same document | No new seal or filing |
| Single export | Stored XML | Bytes identical to seal |
| Period export | Several XML files | ZIP and hash manifest |
| Transmission | Outside BelloPOS today | Separate receipt to retain |
The feature starts with Go and works offline. It cannot prevent loss of the PC, so it does not replace backup. Hash helps verify a restore; it restores nothing. Pair it with invoice retention controls.
Mistakes to avoid
- Hashing PDF when the manifest describes XML.
- Comparing only part of the string.
- Calculating after opening and resaving the file.
- Keeping file and sole reference in one modifiable folder.
- Calling a hash an electronic signature.
- Presenting it as a DGI receipt.
- Ignoring a mismatch because the invoice looks the same.
- Never checking restored copies.
Frequently asked questions
Does SHA-256 encrypt an invoice?
No. It does not prevent reading or recover content. Encryption provides confidentiality; SHA-256 provides integrity evidence here.
Can XML be rebuilt from its hash?
No. The fingerprint is one-way. Retain the file and its backups.
Do identical files have the same hash?
Yes when their bytes are exact. A mere encoding change can produce another result.
Is SHA-256 an electronic signature?
No. A signature adds a signer relationship and key verification; the hash alone does not.
Does the hash prove DGI filing?
No. Only an official-channel response documents receipt or status. BelloPOS does not submit directly today.
Why hash at issue time?
It links structured content to the newly numbered document and lets BelloPOS re-export the same bytes later.
What to take away
SHA-256 answers one narrow question well: is this file identical to the reference? It does not answer who, when, why, tax correctness or DGI acceptance. Use it inside an evidence chain, never as shorthand for all compliance.
Sources
The figures and rules quoted above come from these pages, read on the date given in the article.
- BelloPOS electronic invoicing and UBL export, read 29 August 2026
- Official Universal Business Language 2.1 specification, OASIS
- Moroccan General Tax Code 2026, DGI, read 29 August 2026
Seal, export and verify locally
Test BelloPOS Go with a sample invoice, recalculate SHA-256 and have the same copy verified after accountant hand-off.
Read next
Other practical guides on the same subject: