Rectification with receipt recovery

If an event was already submitted by another system and the next action in Guidis Reinf is a rectification, the product queries the tax authority by the fiscal key and recovers the original receipt when it exists - with no need to type that receipt manually.

• Queries the tax authority by the fiscal key before the rectification
• Recovers the original receipt when the event already exists
• Reduces the need for an external manual lookup to find the previous receipt

What this flow solves

The point is not to import a complete receipt history. The gain is not depending on a manual search when the rectification needs the receipt of the original event already submitted by another system.

This is the typical system-switching scenario: the company is starting to operate in Guidis Reinf, but part of the fiscal history was submitted before. When the next action is a rectification, the product should help locate the right reference instead of pushing the search to spreadsheets, e-CAC or screens from the previous system.

• When the automatic lookup kicks in - the flow applies when the fiscal key already exists at the tax authority and the next action in Guidis Reinf is a rectification. The original receipt is referenced with no manual typing, with less risk of rectifying with incomplete data.
• How the rectification proceeds - after recovering the receipt, submission, proof and tracking continue in the same operational trail of the product, with environment and period explicit. Portal and Reinf API follow the same operation.

Real flow

1. Adjust the entry - the team changes the fiscal data and saves in the same operational flow.
2. Generate the rectification - the system recognizes the previous event and keeps using the correct receipt.
3. Confirm and prove - receipt and proof stay accessible without leaving the period trail.

See also EFD-Reinf messaging and the API documentation.