Reporting financial institutions in Pakistan file under two regimes each year. FATCA data goes to the IRS through IDES by 31 March. CRS data goes to FBR through the AEOI portal by 31 May. The dates are close enough that one preparation cycle should feed both — and far enough apart that teams who treat them separately do the same work twice.

What goes wrong

The failures we see are rarely about the law. They are about data and schema.

  1. Classification drift. Accounts opened during the year are not classified, or indicia reviews are stale. The reporting population is wrong before conversion even starts.
  2. Schema changes. The IRS and OECD both revise schemas. Last year's XML that validated cleanly can fail this year unchanged.
  3. Late validation. Teams convert in the final week, discover hundreds of record-level errors, and have no time to fix source data.

A sensible calendar

  • December–January: classification review and indicia refresh. Confirm GIINs and reporting entity structure.
  • February: extract, populate the reporting template, and run a first validation pass. Fix source data while there is still time.
  • March: FATCA conversion, final validation, IDES submission — before the 31 March deadline, not on it.
  • April–May: CRS conversion from the same prepared data, AEOI portal submission before 31 May.

Nil returns still count

An institution with no reportable accounts still has filing obligations. A compliant nil return is quick to produce — an absent one invites questions.

If your validation errors arrive in the last week of March, the calendar has already failed. Start the data work in the new year.