Certified PDF reports: codes, hashes, signatures and what a recipient can verify

1. The PDF in the mailbox

A statement of account, a balance confirmation, a certificate of payment: the recipient opens a PDF from an e-mail and acts on it. A bank accepts it as proof of receivables, an auditor files it, a customer pays what it says. Nothing in that PDF tells the recipient that it is the document the company issued. PDFs are edited in a minute, the sender address of an e-mail is forged in less, and the "printed on" line is just text. Invoice fraud works exactly like this: an authentic-looking statement with a different bank account.

The company has the mirror problem. When a customer disputes a balance three months later and produces "the statement you sent", nobody can say whether the file is the one that left the server. Both sides need the same thing: a way to tie a file to a record of its issue that neither of them can alter.

2. Three layers, three questions

They are complementary. The hash is the fact, the code is the way an ordinary recipient reaches that fact, and the signature is the way a PDF reader checks it offline. A "certified" report should have all three, and the issuer should keep the record for as long as the accounting records are kept.

3. Designing the verification code

The code is what a person types from a printed page, so it must be short, unambiguous and useless to guess. The conventions that work:

• Twelve characters in groups of four, such as XXXX-XXXX-XXXX, from an alphabet without look-alikes, or treated as such on input: 0 and O, 1 and I are read as the same character. People type what they see.
• Random, not sequential. A code derived from the invoice number lets anyone enumerate the company's documents. Random codes with a large alphabet make guessing a working one impractical, and the lookup must be rate-limited so that nobody tries.
• A QR code next to it encoding the URL https://<portal>/verify/<code>, so a phone camera lands on the result. The domain in the URL is part of the proof: the recipient should recognise the company's own address, not a vendor's.
• In the footer of every page together with "page X of Y", so a single page taken out of a statement still identifies itself.

4. What the public page may disclose

The verification page is public by design: a recipient without an account must be able to use it. That bounds what it may show. The right answer is facts about the issue, never the document:

• the issuer (the company name), the report, the file name and size;
• the issue date and time;
• the SHA-256 of the issued file, and whether it was digitally signed;
• the result of comparing an uploaded file with that record: identical, or different.

Not the file, not the recipient, not the amounts, not the business partner. The page should hash the uploaded file and discard it; storing what strangers upload is a liability, not a feature. A code that was never issued returns "no document was issued with this code", and the same message for a code that expired with retention, so the page does not reveal which codes once existed.

5. Signing without a ceremony

Digital signing of batch output fails in practice when it needs a person: a smart card, a PIN, a USB token on someone's desk. A scheduled run at 06:00 cannot ask. The workable pattern is a company certificate in the server's certificate store (on Windows, the Local Machine Personal store), with the private key readable by the service account only and never exported. The signature is applied as the PDF is produced; Acrobat shows the document as signed and unmodified, with the company's name, and warns the moment a byte changes.

Whether the certificate chains to a public authority is a business decision: a certificate from a qualified trust service provider gives legal weight in some jurisdictions; an internal one still proves integrity to anyone who trusts the company. Either way, rotate it before expiry and record which certificate signed which run.

Two related protections are worth switching on for statements: an open password taken from the recipient's own data (the tax number on file, a customer code) so that a misdirected e-mail does not expose the balance, encrypted with AES-256; and a watermark such as DRAFT or COPY on anything that is not the issued original, so a re-sent copy cannot be passed off as a second statement.

6. Checklist for a statement a third party will accept

• Every issued file has its SHA-256 recorded in a store the issuing system does not let users edit.
• Every page carries a verification code and a QR code to the company's own portal address.
• The verification page compares an uploaded file against the record, shows only issue facts, stores nothing and is rate-limited.
• The PDF is signed with the company's certificate; the private key stays on the server.
• Drafts and re-sends are visibly watermarked; only the original is unmarked.
• The record of issue (who ran it, when, to whom, which file) is in an audit log that detects tampering, kept at least as long as the retention of the files.
• The sent file is also filed where the company's own staff look: on the business partner in SAP Business One.
• Recipients are told once, in the e-mail body, how to verify, and that nobody will ask them to change a bank account by e-mail.

7. How CertiReport does it

Every file CertiReport produces keeps its SHA-256. A certified PDF gets a verification code in the format XXXX-XXXX-XXXX printed in the footer of every page next to "page X of Y", with a QR code to {PublicUrl}/verify/{code}, the public address set under Administration › Settings. The /verify page of your portal, and GET or POST /api/v1/verify/{code}, show the issuer, report, file name, issue date and time, size, hash and whether the file was digitally signed, then compare a dropped PDF byte for byte and answer "Authentic" or "Does not match"; 0 and O, 1 and I are read as the same character, the uploaded file is hashed on the server and not stored, nothing but those facts is exposed, and the public endpoints are limited to 30 requests per minute per client address.

Signing is per company: the thumbprint of a certificate in the Local Machine Personal store of each engine server, applied as a PKCS#7 signature so that Acrobat shows the document as signed and unmodified; Check on the company page tells you whether the service account can read the private key. An optional open password comes from a template expression such as the business partner's tax number, encrypted with AES-256. Page size, orientation and a watermark are per output; on-demand runs of an unpublished report version are watermarked DRAFT and retried items COPY. Every run, item and delivery attempt is recorded, the audit log is hash-chained, runs and their files are kept for 400 days by default, and after delivery the file can be attached to the business partner and logged as an activity in SAP Business One through the Service Layer. See the certification section of the features or book a demo.

References

• ISO 32000-2 (PDF 2.0): digital signatures and encryption
• FIPS 180-4: Secure Hash Standard (SHA-256)
• RFC 5652: Cryptographic Message Syntax (PKCS#7)
• ISO/IEC 18004: QR Code bar code symbology