Path map
Automatic recovery
Lambda’s recovery watchdog looks for stamp work that can safely continue without changing fiscal intent.1
Detect stuck work
Never-started invoices or durable attempts that can resume without remapping.
2
Continue exactly
Re-enqueue from persisted intent, or resume the current attempt with the same request and key.
3
Stop when unsafe
Exhausted recovery becomes a system error. Support starts a new corrective plan — recovery does
not escalate into silent remap.
Workspace: Retry stamp
When the invoice note’s classification allows it, the workspace shows Retry stamp. That action is still policy-bound: Lambda chooses resume vs reprocess from evidence. If the button is missing, the document is usually failed for review, waiting, already successful, or reserved for support — not “broken UI.” Read the note and classification first: Failures, System errors, Troubleshooting.Workspace: Retry CargoWise delivery
Retry stamp delivery or Retry cancellation receipt delivery only re-sends XML/PDF (or the cancellation receipt) to CargoWise inbound. The CFDI may already be issued. Delivery retry does not call Facturapi to stamp again.Source change decisions
When later CargoWise evidence differs from what Lambda used, the workspace can surface a source-change decision.- Accepting and retrying only proceeds when the change is retryable under policy.
- Rejecting leaves the fiscal document alone instead of forcing a remap.
- Post-stamp drift that would create a conflicting CFDI is not auto-healed by another stamp.
Client fiscal correction
Some documents need a complete, Facturapi-validated fiscal profile before a corrective overlay is allowed on one planned attempt.1
Validate the fiscal profile
Lambda checks the corrected client fields with Facturapi before any stamp plan is trusted.
2
Preview the plan
A plan hash is shown. Bulk corrections still preview first; nothing applies without that hash.
3
Apply with a reason
Confirming queues the corrective retry for the exact previewed plan. The reason stays on the ops
run.
Support-owned corrective retry
Support uses corrective retry when the workspace correctly blocks day-to-day action — for example a failed document after a proven mapper fix, or a misrouted invoice that needs a version-aware remap. What you should expect from that path:- Evidence first (original capture vs current claim).
- A fresh preview and plan hash.
- Apply only that hash, with a ticket or explanation stored privately on the run.
- Timeline claims such as resumed or reprocessed, then normal stamp terminal events.
- No customer notification from retry itself.