Whether original invoice bytes survive decides original versus reconstructed PDF; SHA-256 verifies integrity

Two renders of the same invoice can match on screen and differ in every byte. The post names where the drift comes from: object ordering, metadata timestamps, font subsets, compression and producer fields ^[2]. Every one of those fields is set by the writing toolchain. "PDF is a file format, not a promise that two visually similar files have the same bytes," the author wrote ^[3].

So the workflow verifies the digest before anything reads the file. The `verifySource` function reads the stored file, computes a SHA-256 over the bytes, compares it against the `expectedSha256` in the dispute record, and throws a digest mismatch error when the two disagree ^[8]. It then checks that the first five bytes are `%PDF-`, and throws if they are not ^[9]. Both branches throw. "A changed file is a new fact that needs review, not a formatting problem to hide," the author wrote ^[10].

The copy path is the cheap half. `copyVerifiedPdf` hashes the file before the copy and again afterwards and throws `evidence copy changed bytes` when the digests differ, so a case-management system gets a local working copy while the evidence vault stays untouched ^[13].

Replay is the expensive half. Money is serialized as integer minor units, line items sort by their stored sequence, the timezone is an explicit IANA name, and the exact font files are embedded ^[14]. A current-date helper is out, because the post says it guarantees drift ^[16].

The failure modes explain the pinning. A tax rate lookup performed during replay can pick up a later rule ^[18]. A database query without `ORDER BY` can move line items ^[19]. Font fallback changes glyph widths, and different widths change line wrapping and pagination ^[20]. PDF metadata can carry hidden state such as a creation time or a producer field ^[21].

The acceptance test for a replay compares page count, extracted text, bounding boxes and a rendered image checksum at a fixed DPI, and the post says to report the byte checksum next to those results even though it is expected to differ once the renderer rewrites metadata ^[17]. A checksum you expect to fail is an unusual line item in an acceptance test. Four comparisons plus the byte digest makes five reported results, and one of the five is expected not to match ^[22].

On the evidence here, re-rendering does not destroy anything by itself. "Identical visual output is not identical evidence," the author wrote ^[12]. The loss happens in the write path. A content-addressed key, `invoices/{invoiceId}/{sha256}.pdf`, makes an accidental overwrite obvious and lets a dispute worker fetch the exact object an auditor selected ^[6]. The original stays immutable, and a correction becomes a new artifact with a reason and a link to its predecessor ^[7].

The digest has a narrow job. It proves which bytes were examined; it does not prove the invoice's business truth. The input record sits beside it ^[5]. This is one practitioner's workflow published on dev.to, and it does not cite a regulator, a court rule or an audit standard ^[24]. If I were adding one piece of it first, it would be the digest check: a few lines of Node, and a changed file stops the case ^[8][10].