DeclarationsWorkflow
Keep declaration corrections and approval history together
When source data changes, the team needs to distinguish a new preparation from the version already approved or submitted. A version history makes this possible without relying on filenames such as final-new-corrected. Each prepared declaration should remain connected to the inputs and decisions that produced it.
Preserve the declaration that was actually reviewed
The authorized specialist determines whether a change requires a correction and which official procedure applies. The workflow provides the evidence for that decision and records its outcome. It should not treat every source edit as permission to resubmit.
Freeze the preparation inputs
Keep the relevant accounting or operational snapshot, mapping configuration and form version. Link these to the generated document. A later export may contain revised values, but it must not replace the historical basis of an earlier declaration.
Define what counts as a meaningful change. A filename change is different from a changed amount or taxpayer identifier. Show substantive differences in business terms so the reviewer can focus on the affected fields rather than compare entire files manually.
Capture the reason and decision
A correction request should explain the issue, the source of the new information and the proposed replacement values. Attach evidence where necessary. Record who requested the review and who decided the fiscal treatment.
The decision may be to prepare a new version, seek more information or leave the existing declaration unchanged. All three need a clear outcome. A rejected correction request can be useful evidence when the same question appears later, provided its context and reasoning are preserved.
Connect the new version to the earlier attempt
If a new preparation is approved, link it to the version it supersedes or supplements under the agreed procedure. Preserve the original submission and receipt. The timeline should show the relationship without implying that the earlier record never existed.
Use current ANAF form instructions to verify the appropriate supported process. Different forms and circumstances can require different handling. The interface can guide the authorized operator through the agreed route while keeping the form-specific decision explicit.
Restrict edits after approval
Separate drafting permissions from the authority to approve and submit. Changes after approval should produce a new reviewable version rather than silently alter the released document. Include taxpayer context in every background operation and stored response.
Correction evidence can contain sensitive financial or personal information. Limit access to the relevant company and task. Keep secrets out of document history and avoid distributing complete files through notification messages. Define how archived versions remain available to authorized reviewers.
Test reconstruction, not just the latest file
Rehearse a correction before submission, one after a receipt arrives and two competing requests. Verify that each decision references the input version the reviewer saw. Include a failed new submission so the original outcome remains visible.
Measure time to identify affected fields, corrections lacking a reason and cases where source evidence cannot be recovered. Ask another specialist to reconstruct the sequence from the stored records. If they must search personal email, the version history is missing part of the operational story.
Compare the decision trail, not only the numbers
A version comparison should identify which changes matter to the specialist. Distinguish new source facts, mapping changes and corrections to a prepared field. Two documents with different totals may result from the same unchanged source interpreted differently; two equal totals may conceal changes in contributing records.
Use the cases below to define the history your team needs. Preserve the decision that connects one version to another and the official evidence attached to each attempt. This allows review to continue even when the person who made the original correction is unavailable.
| Situation | Evidence to inspect | Decision or next action |
|---|---|---|
| A source record is corrected | The earlier and later source snapshots identify the changed fact, its origin and the person responsible for the correction. | Create a reviewable difference linked to the prepared fields it affects, leaving the previous source snapshot available for reconstruction. |
| The mapping rule changes | The underlying records are unchanged, but a configuration update produces different prepared values or classifications. | Ask the specialist to approve the interpretation and evaluate affected unsent preparations before adopting the new mapping routinely. |
| A proposed correction is rejected | The request, evidence and reviewer reasoning explain why the existing declaration remains the chosen record. | Retain the request with its outcome so the same question can be understood later without being submitted again as new work. |
| A new version is approved | The approval identifies the exact generated document and its relationship to the earlier preparation or submitted attempt. | Record the authorized next action separately and preserve both versions rather than overwriting the file previously used. |
| The new attempt fails technically | The corrected preparation is approved, but the subsequent submission or retrieval has an unresolved technical outcome. | Keep the earlier official evidence visible while assigning recovery for the new attempt to the appropriate operator. |
| Two corrections arrive together | The requests refer to overlapping fields or depend on different versions of the same source records. | Resolve their ordering and combine only the changes the specialist accepts, with each request's contribution preserved in the resulting version. |
Scope a correction workflow for one declaration
RDC can build snapshots, meaningful comparisons, approval history and linked submission attempts around your chosen declaration process. The specialist supplies the current form-specific rules and determines the fiscal action.
Bring redacted examples of an original preparation, the changed input and the resulting review. We can propose an implementation with explicit access and acceptance checks. The team gains a reliable way to explain what changed, who accepted it and which official result belongs to each version.
Inside the product
Declarations
Follow the references
Sources & inspiration
ConsentDocs
Devpost project by ILoveBuns Ren
Extracted facts with human review.
This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.
Put the guide to work
Start with your workflow.
Tell us what your team needs to do, which systems are involved and where the current process slows down.