QAP DAT File Rejected as Invalid Record? Fix a Field Count Mismatch

A QAP DAT file rejected as an “invalid record” almost always means one row has the wrong number of delimited fields — not a bad TIN, ATC, or amount. An extra or missing comma, tab, or pipe character shifts every field after it one position to the left or right, so the BIR Alphalist Data Entry and Validation Module can’t map the row to the Quarterly Alphalist of Payees (QAP) layout at all and throws a structural “invalid record” error instead of a specific data complaint.

This is a different failure class from the data-value errors covered in Common QAP DAT File Errors — a wrong TIN or ATC is a field that’s present but incorrect; a field count mismatch means the row doesn’t even have the right number of fields for the module to check values against. This guide shows where the mismatch comes from, works a concrete example, and walks through the fix.

What does “invalid record” actually mean on a QAP DAT file? #

“Invalid record” is the BIR Alphalist Data Entry and Validation Module’s way of saying it could not parse a row into the fixed set of fields the QAP layout expects — before it ever gets to checking whether the TIN, ATC, or amounts in those fields are correct. A DAT file is delimiter-separated: every payee row must contain exactly the number of fields the layout defines, in the same order, separated by the same delimiter throughout the file. If a row has one extra field or one missing field, the module can’t align column 4 of that row with column 4 of every other row, so it rejects the whole record rather than guessing which value belongs where.

That distinction matters for where you look first. A TIN-format error or an ATC mismatch points you straight to a specific cell. An “invalid record” or field-count error points you to the row’s structure — count the delimiters first, before touching any individual value.

Where does an extra or missing delimiter actually come from? #

Field count mismatches on a QAP DAT file almost always trace back to how the file was exported from Excel, not to a typo in a single cell. The most common sources:

• A payee name or address field contains the same character used as the delimiter (a comma in Dela Cruz, Juan Jr. on a comma-delimited export) and Excel didn’t wrap that field in quotes when it saved as CSV
• The source spreadsheet dropped a trailing column (a blank “branch code” or “middle name” cell that Excel’s Save As silently trims from the end of the row)
• Rows were copied from two different source files with different column counts and merged without checking that every row still matches the layout
• The export used the wrong delimiter for the module’s expected format — commas where the layout calls for a different separator, or vice versa — so every row is technically “well-formed” CSV but wrong for the QAP schedule

Any one of these changes how many fields a parser finds in the row, which is exactly what triggers the rejection.

Worked example: a comma inside a payee name shifts the whole row #

A single unquoted comma inside a free-text name field is enough to turn one otherwise-correct QAP row into an “invalid record” rejection, because everything after that comma gets read as a new field. The payee below is fictional.

A withholding agent’s Q3 2026 QAP source sheet has this payee: Dela Cruz, Juan Jr. — a sole proprietor whose registered name in the agent’s books includes a comma between last name and first name. Exported naively to a comma-delimited DAT, the row reads like this (fields shown separated by | for clarity, with the actual delimiter being a comma):

Broken row (6 fields instead of 5):

The layout for that line expects five fields — TIN, full name, ATC, income payment, tax withheld. Because the comma inside the name split it into two fields, every value from the name onward shifted one position right: the ATC code WI010 landed in the “income payment” column, the actual income amount landed in “tax withheld,” and the tax-withheld figure fell off the end entirely. The module doesn’t see a wrong ATC — it sees a row with six fields where five were expected, so it flags the record as invalid rather than attempting to interpret it.

Fixed row (5 fields, name field quoted or the internal comma removed at the source):

The fix is made in the source spreadsheet, not by hand-editing the DAT text: either let the export tool quote text fields that contain the delimiter character, or normalize the name field so it doesn’t contain a bare comma before regenerating the file. Either way, the row must come back to exactly five fields before it will pass.

Why format conformity matters beyond just a rejected upload #

A structurally invalid DAT file isn’t just an inconvenience to fix and resubmit — the regulation governing alphalist e-submission treats a file that fails to conform to the prescribed format as if it were never filed at all. Revenue Regulations (RR) No. 1-2014, which amended the alphalist submission rules under RR No. 2-98 as amended, ties format conformity directly to whether a submission counts as received. As summarized in a 2014 tax alert from Grant Thornton Philippines quoting the regulation’s operative language:

“Such alphalist[s] including any alphalist that does not conform to the prescribed format thereby resulting to the unsuccessful uploading into the BIR system shall be deemed not received and shall disqualify the deductibility of the expense for income tax purposes.”

QAP is not the same filing as the employee/payee alphalist RR No. 1-2014 principally addresses, but it runs through the same Alphalist Data Entry and Validation Module and the same structural-conformity logic: a file the module cannot parse into the right number of fields per row is not a file the BIR system will accept as filed. That’s a stronger consequence than a correctable data-value typo, which is why a field count mismatch is worth catching before eSubmission rather than after. We could not confirm a specific, separately-numbered BIR issuance that prescribes the exact per-field delimiter count for the current QAP record layout itself (as opposed to the general alphalist format-conformity rule above) — that detail lives in the Validation Module’s own file-structure job aid rather than in a published RR or RMC we could verify, so treat the module’s own layout documentation as the authoritative field count for your filing period, and treat RR No. 1-2014’s conformity principle as the reason a mismatch is a filing problem and not just a technical nuisance.

How do you find and fix a field count mismatch before eSubmission? #

Fixing an “invalid record” error means locating the exact row the module flagged, counting its delimiters against the layout’s expected field count, and correcting the source spreadsheet — never the DAT text file directly. Work through these steps in order:

1. Open the validation report and note the exact row number (and, if given, the field position) the module flagged as an invalid record.
2. Open the DAT file in a plain text editor and count the delimiters in that specific row; compare the count to the number of fields the QAP layout defines for a detail record.
3. If the row has one extra delimiter, scan the free-text fields (payee name, address) for a stray comma, tab, or pipe character that matches the file’s delimiter.
4. If the row has one fewer delimiter, check for a dropped trailing field — a blank branch code, middle name, or similar column that an Excel export can silently omit at the end of a row.
5. Compare a few neighboring rows that passed validation to confirm you know the correct field count and order for this schedule and module version.
6. Make the correction in the source Excel sheet — quote or clean the offending text field, restore the missing column — not by manually editing the generated DAT file.
7. Regenerate the DAT file from the corrected source and re-run it through the BIR Alphalist Data Entry and Validation Module.
8. Repeat until the validation report shows zero errors, then proceed to eSubmission as described in How to Validate a BIR DAT File Before eSubmission.

How is this different from a TIN, ATC, or amount error? #

A field count mismatch is a structural problem — the row has the wrong number of fields, full stop — while a TIN, ATC, or amount error is a data-value problem in a field that’s structurally present and correctly positioned. The two failure classes need different first moves: for a data-value error, you check the content of a specific, correctly-located field (is this TIN the right length? is this ATC valid for this payee type?); for a field count mismatch, you count delimiters first, because until the row has the right number of fields, checking any individual value is checking the wrong column entirely. Common QAP DAT File Errors covers the data-value side — TIN format, ATC mismatches, incomplete names, and amount reconciliation. For background on what a QAP DAT file is and what it attaches to, start at What Is QAP?

Summary #

An “invalid record” or field count rejection on a QAP DAT file is a structural problem, not a data-value one: a row has the wrong number of delimited fields, most often because a stray delimiter sits inside a free-text name field or a trailing field got dropped during an Excel export. Fix it by counting delimiters in the flagged row against the layout’s expected field count, correcting the source spreadsheet (never the DAT text), and re-validating until the BIR Alphalist Data Entry and Validation Module reports zero errors. For the data-value errors that look similar but need a different fix, see Common QAP DAT File Errors; for the validation workflow itself, see How to Validate a BIR DAT File Before eSubmission; and for what QAP is and when it’s due, start at What Is QAP?.