Why Your BIR DAT File Shows an 'Invalid ATC' or 'ATC Not Found' Error, and How to Fix It

A BIR DAT file fails validation with an “Invalid ATC” or “ATC Not Found” error when at least one row’s Alphanumeric Tax Code doesn’t match an entry in the Alphalist Data Entry and Validation Module’s current code table — most often a typo, a code borrowed from the wrong filing type, or a code the BIR has since retired or replaced. The fix is always the same: look up the correct, currently valid ATC for that exact payment type and filing type, correct it at the source, and regenerate the file rather than patching the exported .dat file directly.

What actually triggers an invalid ATC error? #

The Alphalist Data Entry and Validation Module checks every row’s ATC field against a built-in table of codes valid for that specific filing type and module version — a code that isn’t in the table for that form, or isn’t in the table at all, fails the row regardless of whether the rest of the row’s data is correct. This is a code-level check, separate from the amount, TIN, or period checks covered in Excel to BIR DAT File: The Most Common Validation Errors and How to Fix Each One.

Three situations account for most invalid-ATC rejections:

• Wrong filing type — a QAP DAT file row carrying an ATC from the BIR Form 2307/1604-E professional-fee table when the module version in use expects QAP-specific codes, or vice versa.
• Retired or superseded code — a code valid under an older module version no longer appears in the table after the BIR updates it.
• Typo or blank field — a transposed character, an extra space, or a header label like “ATC” accidentally copied into a data row instead of an actual code.

Why can a code that worked last quarter suddenly fail? #

The ATC table itself isn’t static — it changes whenever the BIR releases a new version of the Alphalist Data Entry and Validation Module, and a code valid under an older version can be rejected the moment a taxpayer upgrades or the BIR requires the newer version for submission. This is a real, documented pattern, not a hypothetical: Revenue Memorandum Circular No. 15-2025 announced Version 7.4 of the module —

“Revenue Memorandum Circular No. 15-2025, which introduced Version 7.4 of the Alphalist Data Entry and Validation Module with new ATCs and rates” — as How to Correct and Resubmit a RELIEF, SAWT, or QAP DAT File After eSubmission describes it, taxpayers who had already submitted using the older Version 7.3 needed to re-validate and resubmit against the new version once it took effect.

An ATC table change like this is exactly why a DAT file that validated cleanly in one filing period can fail on the identical code in the next — nothing about the taxpayer’s own data changed, but the table it’s being checked against did.

A worked example: a QAP row rejected for an outdated ATC #

A bookkeeper preparing a client’s Q3 QAP DAT file copies the prior quarter’s spreadsheet forward, changes the amounts, and exports the file without checking whether the ATC column still matches the current module version’s table. The figures are fictional.

The amount, TIN, and period on that row were all correct — the row failed purely because the code table it was checked against had changed since the code was first used. Regenerating the file with the current version’s correct ATC, rather than hand-editing just the code field in the already-exported .dat file, keeps the header and trailer records in sync with the corrected data.

How do you fix an invalid ATC error? #

1. Open the BIR’s current Alphalist Data Entry and Validation Module and confirm which version you’re validating against — the version number is shown in the module itself.
2. Look up the correct ATC for the exact payment type and filing type (QAP, SAWT, RELIEF, or alphalist) in that version’s own code table, rather than reusing a code from memory or a prior quarter’s file.
3. Correct the ATC in the source spreadsheet, not in the exported .dat file — hand-editing a DAT file risks breaking the delimiter or record structure around the field you’re changing.
4. Confirm the withholding rate on that row still matches the corrected ATC — some ATC corrections change the expected rate, not just the code.
5. Regenerate the entire DAT file from the corrected spreadsheet and re-run it through the Validation Module before resubmitting.

Frequently asked questions #

What does an ‘Invalid ATC’ or ‘ATC Not Found’ error mean on a BIR DAT file? #

It means the Alphanumeric Tax Code (ATC) entered on at least one row doesn’t match any code the Alphalist Data Entry and Validation Module currently recognizes for that filing type — either because the code is misspelled, belongs to a different form, or has been superseded by a module update.

Can an ATC that worked last quarter suddenly fail this quarter? #

Yes, if the BIR releases a new version of the Alphalist Data Entry and Validation Module with an updated ATC table in between. Revenue Memorandum Circular No. 15-2025 introduced Version 7.4 with new ATCs and rates, so a code that validated under the prior version can be rejected once the module is updated, even though nothing in the taxpayer’s own data changed.

Where do I find the correct ATC for a payment? #

The ATC table bundled with the current version of the BIR’s Alphalist Data Entry and Validation Module lists every valid code by form type and transaction. The form-specific BIR Form 2307 and QAP guides on this site also reference the ATC for common payment types, but the module’s own table is the authoritative, current source.

Does using the wrong ATC change the withholding tax rate the DAT file reports? #

It can. Many ATC codes are tied to a specific rate — using the code for a 1% goods purchase on a row that should carry the 2% services code, for example, misstates the rate alongside the code itself. Fixing only the code without checking that the originally withheld amount matches the correct rate can leave the file internally inconsistent even after it passes validation.

Is a typo the only way an ATC error happens? #

No. Besides a straightforward typo, the three most common causes are: using an ATC from the wrong filing type (a 2307-series code on a QAP row, for instance), using a code the current module version has retired or replaced, and leaving the field blank or copying a header label into the data row by mistake.

Summary #

An invalid or unrecognized ATC error on a BIR DAT file almost always comes down to a code the current Alphalist Data Entry and Validation Module version doesn’t recognize for that filing type — whether from a typo, a code borrowed from the wrong form, or a module update like the one RMC No. 15-2025 introduced. The fix is to look up the current, correct code, update the source spreadsheet, and regenerate the whole file rather than patching the exported .dat file. See Excel to BIR DAT File: The Most Common Validation Errors and How to Fix Each One for the other frequent causes of a rejected file, and How to Correct and Resubmit a RELIEF, SAWT, or QAP DAT File After eSubmission for what to do if the error surfaces only after the BIR has already acknowledged the original submission.