Why Does Your BIR DAT File Upload Successfully but Show Zero Records Processed?

A BIR DAT file can receive a “successfully uploaded” reply from BIR eSubmission and still show zero records processed, because that reply confirms the email attachment arrived — not that the Bureau of Internal Revenue’s Alphalist Data Entry and Validation Module actually read any detail rows inside it. A total line-ending mismatch, a filtered Excel export, or a subject line routed to the wrong filing type can each leave a file structurally acceptable enough to receive without producing a single countable detail record, with no error message naming the cause.

What does “zero records processed” actually mean in BIR eSubmission? #

“Zero records processed” means the BIR’s system logged the detail-record count it actually read from the file as zero (or far below the expected total), as distinct from the separate confirmation that the emailed attachment itself was received. As this site’s guide to BIR eSubmission covers, eSubmission (the BIR’s electronic facility for receiving validated DAT files such as Reconciliation of Listing for Enforcement (RELIEF) SLSP, Summary Alphalist of Withholding Agents (SAWT), and QAP submissions) is an email-based facility at esubmission@bir.gov.ph that replies confirming whether a file was uploaded to the BIR’s data warehouse or failed validation. A zero-records result sits in an uncomfortable middle ground: the file was accepted as an attachment, but whatever downstream process — the Alphalist Data Entry and Validation Module’s own report, or the BIR’s processing summary — counts the actual detail rows comes back with nothing counted, instead of either a clean pass or a named rejection reason.

This is mechanically different from the more familiar trailer-count-mismatch error this site has already covered in Excel-to-DAT record layout mistakes: a mismatch error names two different numbers (declared vs. actual) and tells you they don’t agree. A zero-records result doesn’t necessarily name a mismatch at all — it can mean the parser never got far enough into the file to count anything beyond the header, or that the file genuinely, internally consistently, contains no detail rows.

Cause 1: A total line-ending mismatch turns the whole file into one unparseable line #

When every line-ending character in a DAT file is converted the same way — not just some of them — the BIR’s line-reading routine can find no breaks after the header, so it never reaches a point where it counts detail rows at all; the result is zero records processed, not a named mismatch error. This is the sharper, less common edge case of the line-ending problem already documented on this site: preparing a DAT file on a Mac or Chromebook explains how a partial line-ending change — some lines affected, not all — produces an explicit record-count-mismatch error, because the parser can still split the file into some lines and compare that count against the trailer. A total conversion is different: with no line breaks left for the parser to recognize at all, there’s nothing to compare, so the check that would normally flag a mismatch never runs.

Worked example: a QAP DAT file that “uploaded fine” but processed zero of 60 records #

A fictional bookkeeper preparing Dado Hardware Supply’s (TIN 234-567-890-000, fictional) Q3 2026 Quarterly Alphalist of Payees (QAP) DAT file for 60 payee rows generates the file with a converter that correctly writes Windows-style CRLF (\r\n) line endings — the convention the BIR’s own Windows-built module expects. Just before sending, she opens the file in a Linux-based text editor to delete one stray blank line at the end, and saves it. That editor’s default save setting silently rewrites every line ending in the file from CRLF to a bare LF (\n), not just the one line she touched.

The file she sends still looks identical on screen — every TIN, ATC, and amount is exactly as entered — and the BIR’s eSubmission reply still confirms the attachment was received, because the mail-level acceptance check doesn’t depend on line-ending format. It’s only when the Validation Module (or the BIR’s downstream processing) tries to split the file into individual records that the total line-ending change becomes visible, and because it finds no detail lines to count at all, it reports zero rather than naming a specific row or field problem. The fix is the same discipline this site’s record-layout guide already establishes: regenerate the file from the original converter output rather than re-saving it in a text editor, and never treat a generated DAT file as something safe to open and touch up.

Cause 2: A filtered or hidden-row Excel export produces a file that’s correctly empty #

A less exotic but equally silent cause is a filter left active in the source spreadsheet at export time: some conversion paths only pick up the rows currently visible on screen, and if the filter hides all the rows that should be included, the exported file ends up with a header and a trailer that correctly declare zero detail records. This is a materially different failure from the line-ending case above — nothing is corrupted or misread; the file is internally consistent (zero declared, zero actual), so a structural check has nothing to flag as wrong. The only thing wrong with it is that it doesn’t reflect the quarter’s real transactions.

This typically happens when a filter applied to spot-check one payee, confirm a total, or isolate a correction is never cleared before the file is generated. The exported DAT file validates cleanly — zero detail rows is not, by itself, a structural error — and the eSubmission reply confirms receipt, leaving the filer with a filed-looking submission for a quarter that actually had dozens of transactions.

How to tell which cause you’re dealing with #

Diagnosing a zero-records result means checking three things in order: whether the source data was filtered at export time, whether the generated file’s line endings are consistent throughout, and whether the file was sent under the correct filing-type subject line — because each produces the same symptom through a different mechanism.

A trailer count that matches the file’s own content (whether that’s 60 or zero) only tells you the file is internally consistent — it does not confirm that count matches what the source data should have produced. That comparison against the source has to be done separately, which is exactly what a zero-records result can hide from a filer who only checks the eSubmission reply.

Is a zero-records result always a mistake? #

No — a legitimate nil filing and a silent failure both produce a file with zero detail records, and the only way to tell them apart is intent, not the file itself. A taxpayer with no sales, purchases, or withholding to report for a given period can and should still file a DAT-based submission for that period, and the BIR’s own Alphalist Data Entry and Validation Module supports this directly: when the detail schedule is left empty (without deleting the header), the module tags the file as having no entries rather than treating an empty detail section as an error. A tax-advisory summary of Revenue Memorandum Circular No. 44-2021 describes this same expectation for the quarterly Summary List of Sales and Purchases — that the obligation to submit continues even for a quarter with no reportable transactions, filed as a deliberate nil return rather than skipped entirely.

The difference from the two causes above is straightforward: a nil filing is zero records on purpose, for a period the filer already knows had nothing to report. A silent failure is zero records when the bookkeeper’s own records show real transactions for the period — the mismatch between what should have been filed and what the BIR actually counted is the signal that something broke, not that the quarter was genuinely empty.

Why the DAT file format makes this failure mode possible at all #

BIR DAT files are built from header, detail, and trailer records in a fixed, delimiter-separated plain-text layout, and that same rigidity that makes the format fast to parse at scale is what allows a file to be read as technically valid while containing far fewer records than it should. Revenue Memorandum Circular No. 19-2015, covering FAQs on the BIR’s electronic filing platforms, describes the expectation behind this structure directly:

“…Summary Alphalists of Withholding Tax (SAWT), Monthly Alphalists of Payees (MAP) required under BIR Form Nos. 1600, 1601E, 1601F… shall be prepared using the Data Entry Module… and submitted via email to esubmission@bir.gov.ph.”

— Revenue Memorandum Circular No. 19-2015, FAQs on the electronic platform for filing tax returns

“Prepared using the Data Entry Module” is the operative phrase: a file built or touched outside that module’s own export routine — including a line-ending change introduced by an unrelated text editor, or an export taken from a filtered view — can still look like a valid DAT file on screen while carrying a byte-level structure the BIR’s parser reads differently than the filer intended. For the full three-part record structure this failure mode exploits, see Excel-to-DAT record layout mistakes; for the general list of validation errors a file can surface before it even reaches this stage, see BIR DAT File Validation Errors and Common Fixes.

What to do if you catch a zero-records result #

Treat a zero-records result as an unfiled submission until a corrected file shows a detail count that matches the source data — the eSubmission “received” reply is not, by itself, proof that the filing is complete. Work through it in this order:

1. Compare the trailer’s declared count against the source spreadsheet’s actual row count, not just against the file’s own content.
2. Clear every filter and unhide every row in the source spreadsheet before regenerating the file.
3. Check the generated file’s line endings for consistency (CRLF throughout, not a mix of CRLF and LF), ideally by regenerating from the original converter output rather than inspecting the already-sent file.
4. Confirm the subject line and the attached file both match the same filing type and period.
5. Regenerate the entire DAT file from the corrected source — never hand-patch a trailer count or a line-ending inside an already-generated file.
6. Re-validate through the BIR’s Alphalist Data Entry and Validation Module and confirm the report shows the expected detail count, not just zero errors.
7. Resend the corrected file to esubmission@bir.gov.ph before the deadline. See How to Correct and Resubmit a RELIEF, SAWT, or QAP DAT File After eSubmission for how a correction after an earlier acknowledgment is handled.

Frequently asked questions #

Why does a BIR DAT file show zero records processed even though eSubmission said it was received? #

Because the BIR eSubmission facility’s “file received” reply confirms the email attachment arrived, not that the Alphalist Data Entry and Validation Module successfully read every detail record inside it. A file can be structurally intact enough to accept as an attachment while a line-ending mismatch, a filtered export, or a misrouted subject line leaves the module unable to identify any detail rows, producing a zero-records result instead of a row-specific error.

Is a zero-records result the same as a validation error? #

No. A validation error names a specific problem, such as a trailer count that doesn’t match the file’s actual rows. A zero-records result is different and often quieter: the file passes whatever structural check the parser ran, but the count of detail records it actually processed is zero (or far below what the source data should have produced), with no error message pointing to a cause.

Can a total line-ending mismatch really make a DAT file report zero records instead of an error? #

Yes, as a specific edge case. A partial line-ending mismatch (some lines affected) typically triggers an explicit record-count-mismatch error. But when every line-ending in the file is converted the same way, the parser finds no line breaks at all after the first record, so it never reaches a point where it can compare an actual count against a declared one — it simply counts zero detail records instead of flagging a mismatch.

Can hidden or filtered rows in Excel cause a DAT file to silently export as empty? #

Yes. If a filter is left active in the source spreadsheet when the DAT file is generated, some export methods pick up only the visible rows. If the filter hides all the rows that should be included, the exported file can end up with a header and a trailer declaring zero detail records — a file that is internally consistent (zero declared, zero actual) and does not trigger a structural error, even though the underlying data has real transactions.

Is zero records always a mistake, or can a BIR DAT filing legitimately have none? #

A legitimate nil filing is real and different from a silent failure. A taxpayer with no sales, purchases, or withholding to report for a period can file a DAT submission that intentionally declares zero detail records, and the BIR’s Alphalist Data Entry and Validation Module supports this by tagging such a file as having no entries. The difference is intent: a nil filing is zero records on purpose for a period with nothing to report; a silent failure is zero records when the source data clearly had transactions.

Summary #

A “successfully uploaded” BIR eSubmission reply confirms an email attachment arrived — it does not confirm the Alphalist Data Entry and Validation Module actually counted every detail record inside it, which is exactly the gap that lets a zero-records result slip through silently. The two named causes covered here — a total line-ending mismatch that leaves the parser unable to find any line breaks after the header, and a filtered or hidden-row Excel export that produces a file correctly declaring zero detail rows — both pass whatever structural check runs without naming an error, unlike the trailer-count-mismatch failures covered in Excel-to-DAT record layout mistakes. The only reliable check is comparing the file’s processed count against the source spreadsheet’s actual row count, not just trusting the eSubmission reply or the file’s own internal consistency. For the eSubmission mechanics this builds on, see What Is the BIR eSubmission System?; for the general validation error list this is distinct from, see BIR DAT File Validation Errors and Common Fixes; and for correcting and resending a file after catching a problem like this, see How to Correct and Resubmit a RELIEF, SAWT, or QAP DAT File After eSubmission.