The prefilled JSON is the best thing the e-filing portal gives a CA and the easiest thing to misuse.
It is authoritative about three things and merely suggestive about a fourth, and the difference between those two categories is where returns go wrong. A return built on the prefill agrees with the portal perfectly and can disagree with the client's own books entirely, which is the one error no validation will ever catch.
Here is what the file is actually for, and what belongs in it only as a comparison.
There is no published schema for this file
Worth stating plainly, because it changes how a tool should be built and how much you should trust one.
The department publishes a schema for each return form. It does not publish one for the prefill. So anything reading the prefill is reading field paths that somebody worked out, and the only defensible way to work them out is from the department's own offline utility, which imports exactly this file.
That means the import routine inside the department's own ITR-1 and ITR-4 workbooks, and the equivalent one inside the ITR-2 and ITR-3 ones. Those routines are the specification, because they are what the department itself runs against the file.
The rule that follows is narrow and important: read only the paths that utility reads. A field whose name looks like it holds what you want, which the department's own utility never touches, is a guess. It may hold what you expect this year and something else next year, and nobody will tell you when it changes.
Important
A prefill reader built from field names rather than from the department's own utility will keep working right up to the year it quietly does not.
What the prefill is genuinely for
Three things, and it is better than any other source for all three.
Identity. PAN, name, date of birth, address. This is the department's own record of the client, and if it disagrees with your file, your file is what needs correcting before anything else happens.
The bank accounts a refund can go to. Not the client's list of accounts. The department's, which is the one the refund will actually use.
The tax credits. What was deducted, collected and paid, with the TAN beside each deduction and the challan beside each payment. This is the material the return's tax schedules are made of, and it is not available anywhere else in that shape. No bank statement carries a BSR code.
- Identity: PAN, name, date of birth, address
- Refund bank accounts, as the department holds them
- Tax deducted, with the TAN of each deductor
- Tax collected, and the client's own challans with the BSR code and serial number
What it must not become
Income.
The prefill carries salary lines and interest lines, and they are there to be compared, not copied. The heads of income on a return are the computation sheet's and nobody else's, because the computation sheet is the thing that was prepared from the client's actual records and that somebody is prepared to defend.
The right treatment is to show the prefill figure beside the computation figure, so the difference is visible, and to leave the return carrying the computation's number. A difference is a question to answer, not an error to silence by adopting the portal's figure.
There is one honest exception. Salary detail from an employer's Form 16 is genuinely the employer's record and fills the salary schedule properly. That is a different thing from taking a total because the portal offered it.
The interest case is the one that bites most often. Bank interest reported gross will disagree with a books figure posted net of TDS every single time, and adopting the prefill figure hides a bookkeeping error rather than fixing it.
Pro tip
If the prefill and the computation disagree on an income figure, write down which one you are filing and why, before you file. That sentence is the whole of your answer if a notice arrives.
The small things that break a reader
Three shapes in this file routinely catch a tool out, and they are worth knowing even if you never write one.
Money arrives as whole rupees, and sometimes as a string. "1500" and 1500 and "1,500" all appear. A reader that assumes a number gets nothing from the rows that are strings, silently, and the return comes out short.
Dates arrive in at least three shapes. 2025-06-15, the same with a time on the end, and 15/06/2025. Any one of them alone is a safe assumption until the file that uses another one turns up.
Single entries are not always arrays. A client with one bank account can get an object where a client with two gets a list. A reader that only handles the list loses the account entirely, and again, silently.
None of these produces an error. All three produce a return that is quietly missing something, which is the failure mode worth designing against.
What a gap should look like
When a figure cannot be stated, the honest output is a gap, not a number.
A computation sheet that could not state a figure, for any reason, including a rule the tool has not verified for that assessment year, should produce a hole in the return with a note saying what is missing. It should not produce a zero, and it should not produce a best guess.
A zero is indistinguishable from a real nil, and it will be filed. A gap stops the file being saved until somebody looks at it, which is the correct outcome, however inconvenient it is at eleven at night in July.
The same discipline decides what number a return file carries as its software identifier: until the department issues one, the honest value is none, not somebody else's.
Conclusion
The prefill is the department's record of who the client is, where a refund should go, and what tax has been paid. On those three it beats anything in your own files and should simply be adopted.
It is not the client's income, and the moment it is treated as income the return stops being a statement of what the books show and becomes a statement of what the portal already believed.
Greenote reads only the paths the department's own offline utility reads, shows the prefill figures beside the computation's rather than over them, and turns a figure it cannot state into a gap rather than a number. The file is built on your PC and you file it. See what the return workspace covers, or start with which ITR form the client can use.
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.
