Import last year’s ITR JSON — onboard a client from one file

Three things it gives you

The client record

Name, PAN, date of birth, address and bank details, read out of the filed return rather than typed from a photocopy. A client can be created directly from the upload.

The carry-forwards

Brought-forward losses, unabsorbed depreciation and credits reach this year’s computation from the imported year. This is the part that is genuinely expensive to do by hand and genuinely damaging to get wrong: a loss that silently fails to arrive is money the client loses without ever seeing a message about it.

The year-on-year comparison

Last year’s figures sit beside this year’s while the return is being prepared, which is how a missing head gets noticed. A client who had interest income last year and none this year is either a changed fact or a forgotten document, and the comparison is what raises the question.

The PAN and year check is strict here. On a prior-year import a wrong file does not merely show a wrong number — it feeds the carry-forwards. So the PAN and assessment year in the file must match the client, and a mismatch is refused.

Both shapes of the CBDT file

The department has changed the structure of its JSON between years. The reader walks both the flat and the nested layouts, because a parser that only knows this year’s shape shows a client a clean set of zeroes for the year before — silently, and with no error anywhere.

Questions

What can last year’s JSON fill in?

The identity the return needs anyway — name, PAN, date of birth, address, bank details — so a new client can be created from the file rather than typed in. The income figures come across as the previous year's comparative.

Does it carry losses forward?

Brought-forward losses, unabsorbed depreciation and credits reach this year’s return from the imported prior year, which is the reason to import it even when the client is already on the roll.

What if I upload the wrong year or the wrong PAN?

It is refused. The PAN and assessment year in the file are checked against the client before anything is read. On a prior-year import this check is strict rather than advisory, because a wrong file would corrupt the carry-forwards rather than just show a wrong figure.

Which forms can be read?

The CBDT JSON as the portal produces it. Both the flat and the nested shapes the department has used are handled, which matters because the structure has changed between years.

Onboard a client from the return they already filed