Reconcile a batch of reports before any file is released

Count intended reports before counting outputs

A folder containing ten PDFs does not prove ten intended reports were generated. It may contain nine unique reports and a duplicate. Begin with a manifest of approved report identities and their input/template versions. Keep attempts underneath those identities rather than treating each attempt as a new report.

This is an original example, not a merchant incident or benchmark. The batch is not complete merely because a process finished running. R-101 can have its own decision while R-102 and R-103 remain unresolved.

Keep four counts with clear meanings

• Intended: unique approved report identities in the manifest.
• Resolved: identities whose generation outcome is established, including confirmed failures.
• Reviewed: identities with an actual file-level decision.
• Released: identities whose authorized distribution step is recorded.

These are not interchangeable success rates. A confirmed failed job can be resolved without being reviewed or released. Track duplicate artifacts separately; do not subtract an inconvenient extra file and pretend the attempt never occurred.

For each intended report, retain a controlled output reference, input version, template version and actual status. Do not put recipient addresses, private content or tokenized download links into a public dashboard or ordinary shared log.

Reconcile provider and local records together

Use the actual returned provider reference when available, alongside your stable report identity. CraftMyPDF’s async monitoring guide describes transaction history for reconciliation. Receiving a callback does not establish that your application stored or reviewed the file.

1. Compare each manifest identity with the submitted attempt record.
2. Match established outputs to the intended input and template version.
3. Investigate missing callbacks without assuming generation failed.
4. Quarantine duplicate or mismatched artifacts from release.
5. Append the finding and owner’s next decision; preserve the original uncertainty.

Do not match only by filenames or approximate timestamps when a stronger job reference exists. If the relationship cannot be established, keep it unresolved.

Keep the batch review finite

At a declared cutoff, report the actual counts and the unresolved identities. An owner can decide whether to release individually accepted reports or hold the entire batch because the recipient needs a complete set. Define that rule before an incident, not after seeing an inconvenient result.

A new generation for one unresolved item is a separate recorded decision. Never replay the entire batch to fix one missing file without considering duplicate charges and deliveries. Keep the accepted template available and use the individual failure guide for the affected attempt.

Turn the incident into a regression case

If a duplicate callback or changed mapping caused the discrepancy, reproduce that behavior with a synthetic case in your own authorized environment. Check that the receiver records the repeated observation without releasing twice. A successful ordinary batch cannot prove that exception handling works.

This guide does not establish concurrency limits, throughput or a safe production batch size. Those require a separately bounded performance evaluation and current provider limits. Its purpose is narrower: make completeness and release decisions observable instead of inferred from a folder count.