Skip to main content
Retry is part of stamping: the recovery and correction paths for stamp work. It is not an everyday accountant action. Most documents stamp once and finish. This section exists so you can see how Lambda protects fiscal integrity when something stalls, a mapping bug is fixed, or a document must be corrected on purpose. Think of it as transparency literature for catastrophic paths inside stamping: what the system will resume, what it will remake, and what it will refuse.

​
What you get

  • Automatic recovery for work that never started or can safely continue the same attempt
  • Deliberate corrective retries when evidence proves a real change (source, fiscal profile, or Lambda version)
  • Hard blocks against re-stamping successful or cancelled CFDIs
  • Preview-before-apply so a retry only runs the exact plan that was just proven safe
  • A durable run history when a corrective retry happens

​
What this is not

Retry is not “press again until it stamps.” It is not a second stamp for a document that already has a SAT UUID. It is not CargoWise delivery retry — delivery of XML/PDF is a separate lane inside the same stamping pipeline. Ordinary document failures still need corrected evidence first. Retry only continues when policy and proof allow it.

​
Who this is for

If you are day-to-day in invoices, start with Statuses and Troubleshooting. Read this section when you need to understand recovery and correction safety.

​
Start here

How it works

Automatic recovery vs corrective retry, and who owns each step.

Strategies

Resume the exact attempt, or remap the original capture and try once more.

Safety rules

What retry never does, and what always blocks it.

Recovery paths

Workspace actions, source changes, fiscal corrections, and support-owned work.