A correction statement is the least documented routine thing a practice does. Everyone knows how to file an original. Corrections get learned by trial, intimation and retry.
The mental model that makes it tractable is this: a correction is not a new statement. It is a set of instructions applied to the statement the department already holds, and every field in it is in one of four states.
Once the four states are clear, the rest of the rules stop looking arbitrary.
The four states every field is in
For a given correction type, each field is one of these.
| State | What it means |
|---|---|
| Blank | No value is to be specified. The field stays empty. |
| Fixed | It cannot be updated. It is carried, and an attempt to change it is refused. |
| Editable | It may be changed, otherwise it repeats what the last statement said. |
| Carried | It repeats the value as the department holds it. |
The published file format sheets say which, field by field and correction type by correction type, in the remarks against each field.
Two consequences follow and both bite. A field marked blank for your correction type must be empty even though it has a perfectly good value in the original. And the fields whose names begin with "Last" are not yours to fill: they repeat the figure as filed, and they are how the system recognises which record you are correcting.
You cannot write a correction without the consolidated file
A correction is written against the consolidated file for that statement, downloaded from TRACES, plus the token number of the last accepted statement for that quarter.
That is not a formality. The consolidated file is where the carried values come from, and the previous token is how the correction attaches to the right version. A correction built from your own copy of what you filed will differ from what the department holds the moment anything has already been corrected once.
The operational trap here is the token. If a quarter has been corrected before, the previous token is the token of the last accepted statement, not the original one. Practices that keep only the original acknowledgement get this wrong on the second correction, and a wrong previous token is a rejection.
Pro tip
Keep the token of every accepted statement against the quarter, not against the filing. The next correction needs the latest one, and the only place it reliably exists is wherever you put it.
Which batch for which change
Corrections come in typed batches, and the type is decided by what you are changing.
| Type | What it changes |
|---|---|
| C1 | The deductor details, but not the TAN |
| C2 | Challans, and the deductor details with them |
| C3 | Deductee lines, updated or added, with the challans and deductor |
| C4 | The fourth quarter salary details, Annexure II |
| C5 | A deductee PAN |
| C6 | The fourth quarter section 194P details |
| C9 | Adding a challan |
They nest, which is why there are fewer decisions than rows. If you are touching deductee lines you are in C3, and the challan and deductor changes ride along. If you are only touching challans it is C2, and only the deductor, C1.
One file holds at most five batches, one of each type, written in order.
The PAN rule that catches everyone
A PAN correction goes in one of two different batches depending on what the PAN currently is, and this is the single most useful thing in this article.
If the line was filed with a stand-in PAN, meaning PANAPPLIED, PANINVALID or PANNOTAVBL, then supplying the real PAN is a C3, a deductee line update. The line never had a PAN; you are completing it.
If the line was filed with a real PAN that was simply the wrong one, that is a C5, a PAN update.
Same apparent change, two different batches, and sending it in the wrong one does not do what you intended. Worth putting on the wall above whoever does corrections.
Important
Deleting a deductee line has been withdrawn. If a line should not be there, it is corrected to nil rather than removed, and a workflow built around deleting lines will not work.
What C9 is, and why you probably cannot use it
C9 adds a challan with its deductees to a statement already filed. It is the obvious answer to "we left a challan out", and it is almost certainly not available to your client.
Adding a challan this way is discontinued except for a Central or State Government deductor, and for those only for the older years. For everyone else the route to a missed challan runs through the online correction facility rather than through a file.
The reason to know this is that the field layouts for C9 are still published in the correction sheets, so a tool reading the sheets will happily offer it. The sheet defining a batch is not the same thing as the department accepting one.
And the same thing from tax year 2026-27
Corrections exist for the renumbered forms too: 138, 140, 143 and 144 each have their own published correction formats.
One difference in the small print is worth knowing. The older sheets carried a general note that marked editable fields with a hash, and a practice could rely on that marking. The 2026 sheets have no such note and mark very few fields, so the hash is no longer the only indicator of a field a CA may change. The rule that still holds is the negative one: a field that is not blank, not fixed and not a "Last" field is a field you may change.
And both will be running at once for years. A correction to a financial year 2024-25 quarter filed next month is still a 26Q correction, with 26Q correction field layouts, whatever year it is filed in. That is the same rule that governs every other form number right now.
Conclusion
Corrections stop being guesswork once the four field states and the batch nesting are clear. Most rejections trace to one of three things: the wrong previous token, a field filled that should be blank, or a PAN change in the wrong batch.
All three are avoidable with a record rather than a memory.
Greenote reads which state each field is in from the published correction sheets themselves rather than from a rule typed by hand, so the writer and the check cannot disagree about what a correction leaves empty. See what the TDS workspace covers, and the lower deduction certificate register that fills the reason flag those lines carry.
Turn bank statements into Tally vouchers on your own PC
Greenote reads 100+ Indian banks and posts clean vouchers straight into Tally, from your own PC. The statement is not uploaded, and nothing is typed by hand.
Free trial: 2 days or 10 statements, no card. Works with Tally Prime & ERP 9.
