Invoice PDF API Workflow: Generate, Deliver, and Archive

Most invoice systems fail in the “last mile”: duplicate sends, overwritten files, or missing proof for what was delivered. A strong workflow treats each invoice as a versioned artifact, not just a generated file.

Reference architecture

1. Build a canonical JSON payload (`tenant_id`, `invoice_id`, `revision`, totals, tax snapshots).
2. Render server-side HTML with locked currency/date formatting and explicit print styles.
3. Generate PDF with PDF Munk and attach metadata (`invoice_id`, `revision`, `issued_at`).
4. Persist immutable storage key + checksum + render config in your ledger table.
5. Send customer notification from an outbox queue only after persistence succeeds.

Idempotency model that actually works

Use an idempotency key shaped like tenant:invoice:revision:templateVersion. If the same request appears again (retries, worker restarts, webhook replay), return the previously stored artifact pointer instead of generating a second invoice.

Delivery strategy

• Store PDF privately; share short-lived signed URLs for customer access.
• For email attachments, include checksum and invoice revision in audit logs.
• Record delivery attempts separately from document generation state.

Production checklist

• Template versioning with rollback support
• Retry budgets + exponential backoff + dead-letter queue
• Checksum verification for tamper detection
• Region-aware storage and retention policy by jurisdiction
• Automated nightly reconciliation (expected invoices vs generated artifacts)

If you implement these controls early, invoice generation becomes a reliable accounting primitive—not a fragile side process.