Practical guide

Review a generated PDF before sending it

Last materially reviewed 2026-10-01

Quick answerTreat generation, acceptance and delivery as separate states.
What to know

Confirm identity and completeness

Match report ID, intended recipient and reporting period with the approved source. Compare required fields, first and last rows and visible section endings. Check that draft labels or test data are absent from the intended release. A successful generation response proves neither that the document is correct nor that it reached the right person.

What to know

Inspect the file as a reader

Open the actual exported PDF. Review page breaks, clipping, headers, captions and the final page at a usable reading size. Test any essential links without submitting forms or exposing private destinations. Keep visual findings distinct from data validation; attractive pages can still contain the wrong information.

What to know

Check structure as well as appearance

W3C’s PDF3 technique explains that reading and tab order depend on document structure, not just visual arrangement. It recommends testing reading order and keyboard focus with appropriate tools. Prefer correct structure in the authoring source. This is one technique, not a complete accessibility audit or certification of any generator; relevant requirements need their own evaluation.

What to know

Record the release decision

An authorized reviewer should record the accepted template version, case or report ID and any approved exceptions. Hold unresolved output; do not silently substitute a newer file after delivery. Distribution permissions, storage and recipient access are separate responsibilities. This publication covers assembly acceptance, not a complete secure client-delivery system.

What to know

Worked hold decision

R-004 contains the correct period and all rows but clips the approved note’s final sentence. Mark identity passed, rows passed, readability failed and release held. Preserve the file and source versions. Do not describe the report as mostly accepted and send it anyway unless an authorized owner explicitly approves a documented exception appropriate to the task. A checklist is useful because it keeps different decisions visible, not because it guarantees correctness.

Continue when useful

Next: Handle failures

Separate a confirmed rejection from an output whose status is unknown.

Open Handle failures →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. W3C PDF3: reading and tab order — Authoritative technical technique · w3.org · External source; not product verification · checked 2026-10-01