Does a BIR DAT File Have a Row Limit? Splitting Large RELIEF, SAWT, or QAP Files

No — the BIR has not published a specific numeric row or record limit for RELIEF, SAWT, QAP, or alphalist DAT files. What actually caps how large a single conversion or submission can be are two separate, practical things: the conversion tool generating the file, and the eSubmission email channel carrying it to the BIR. When a spreadsheet outgrows either one, the fix is splitting it along a real boundary in the data — never by hand-editing an already-generated DAT file.

Is there an official BIR row limit for DAT files? #

No single BIR regulation sets a numeric row or record cap on a RELIEF, SAWT, QAP, or alphalist DAT file. What the BIR has published, going back to Revenue Regulations (RR) No. 1-2014 and Revenue Memorandum Circular (RMC) No. 5-2014, is the file’s required structure — a fixed layout prepared through the BIR’s own Alphalist Data Entry and Validation Module and submitted through one of a small set of defined channels, rather than any cap on how many detail rows that structure can hold. A later circular describing the BIR’s electronic filing FAQs puts the submission requirement this way:

“…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

That requirement is about how a DAT file is built and sent, not about a maximum number of rows it may contain. If a specific, verifiable BIR issuance setting an explicit numeric row limit for these DAT formats becomes available, this guide will be updated to cite it directly — until then, the honest answer is that no such published limit exists, and the real constraints sit one layer down, in the tools and channels used to prepare and send the file.

What actually limits a large Excel-to-DAT conversion in practice? #

Two independent, non-BIR limits do the practical capping: the conversion tool’s own per-file processing ceiling, and the size of an email attachment sent to the BIR’s eSubmission mailbox. Neither is a rule the BIR wrote into a regulation for the DAT format itself — they’re operational limits that exist regardless of which converter or submission method a filer uses.

The first two rows of that table are why a very large spreadsheet becomes a real, practical problem even though the BIR’s own rule doesn’t put a number on it: a converter built to reliably validate and generate a file for a few hundred rows can slow down, time out, or produce a file that’s awkward to hand-check once the source spreadsheet runs into several thousand rows, and a bulky email attachment risks bouncing or being flagged before it ever reaches a BIR reviewer.

When does a large Excel file actually need to be split? #

Splitting becomes worth doing once a single source spreadsheet is large enough that converting or reviewing it in one pass becomes unreliable — not at some fixed row number, but at the point where errors get harder to trace and a failed conversion means redoing everything at once. A few thousand clean, well-formatted rows convert without issue for most filers; the practical trigger is usually one of these:

• The spreadsheet exceeds the converter’s stated per-conversion guidance (see the table above).
• A single validation error forces a full re-check of thousands of rows instead of a manageable few hundred.
• The generated DAT file, zipped or not, is too large to attach to a single eSubmission email without splitting.
• The filing genuinely spans multiple registered branches or TINs that shouldn’t be combined into one file in the first place.

How do you split a large Excel file into multiple clean DAT submissions? #

Split along a boundary that already exists in your data, so each resulting file is a complete, independently valid submission rather than an arbitrary chunk of rows. The three boundaries that hold up in practice, in rough order of how commonly they apply:

1. By taxpayer or branch/TIN. If the spreadsheet actually covers more than one registered entity or branch, each one should have been a separate DAT file from the start — this is the cleanest split and the one least likely to create confusion later.
2. By period within the quarter, where the filing type supports monthly-level detail inside a quarterly return — splitting a quarter’s combined data into its constituent months, each with its own header declaring that month’s period.
3. By document or transaction type — for example, a RELIEF filer’s Summary List of Sales kept separate from its Summary List of Purchases, which the BIR already treats as distinct document types rather than one combined file.

Whichever boundary applies, the mechanical rule is the same: regenerate each split file from its own filtered slice of the source spreadsheet, rather than manually cutting an already-generated DAT file into pieces. This matters because every BIR DAT file — regardless of filing type — is built from header, detail, and trailer records, and the trailer’s declared row count has to match the detail rows actually present in that specific file. Manually splitting a generated file risks leaving a stale trailer count behind, exactly the record-structure failure covered in Excel-to-DAT File Conversion Mistakes: Getting the Header, Detail, and Trailer Records Wrong. Regenerating from source, one filtered batch at a time, keeps each file’s header, detail rows, and trailer count produced together and internally consistent.

Worked example: splitting a 3,200-row RELIEF sales file by month #

A fictional VAT-registered wholesaler shows how a spreadsheet too large for one clean conversion gets split without losing any transactions or corrupting a trailer count. Meridian Trading Corp. (fictional) closes its second quarter of 2026 with 3,200 sales transactions across April, May, and June that need to go into its RELIEF Summary List of Sales. Converting all 3,200 rows in a single pass exceeds the converter’s guidance of roughly 1,000 rows per conversion, and a single combined DAT file of that size is unwieldy to spot-check before submission.

Meridian’s bookkeeper filters the master spreadsheet down to each month, runs each filtered sheet through the converter separately, and validates each resulting DAT file on its own before combining all three into a single zipped attachment for the quarter’s eSubmission email — following the same zip-before-emailing practice covered in BIR DAT File Naming Convention and Folder Structure. Each file’s trailer count matches only its own month’s rows, and the three files together still reconcile to the full 3,200-row quarter reported on the 2550Q.

Frequently asked questions #

Does the BIR publish an official row limit for RELIEF, SAWT, QAP, or alphalist DAT files? #

No specific numeric row or record limit for the DAT file format itself is publicly documented in BIR regulations. What is documented is the file’s required structure — header, detail, and trailer records — and, separately, practical ceilings imposed by the eSubmission email channel and by whichever conversion tool generates the file.

What actually limits how large an Excel-to-DAT conversion can be? #

Two independent things, not one BIR rule: the conversion tool’s own per-file processing limit (BIR Online Tools’ converter, for example, is built around files of roughly 1,000 rows and 10 MB per conversion), and the practical size ceiling for an eSubmission email attachment, which practitioner guidance puts at roughly 20 MB before it should be split.

How should you split a large Excel file into multiple DAT submissions? #

Split along a boundary that already exists in your data — by branch or TIN if you file for multiple registered entities, by month within the quarter if the filing type allows monthly detail, or by document type (sales list versus purchase list). Each resulting file needs its own complete header, its own detail rows, and its own trailer record with a count that matches only that file’s rows.

Does splitting a DAT file risk breaking the trailer record count? #

Yes, if done by hand. The trailer record’s declared row count has to match the detail rows actually present in that specific file, not the original combined spreadsheet. Regenerating each split file from its own filtered source data, rather than manually cutting an already-generated DAT file into pieces, keeps the header, detail, and trailer records internally consistent.

Do RELIEF, SAWT, and QAP all use the same row-limit rules? #

They share the same underlying header/detail/trailer mechanics and the same eSubmission email channel, so the same practical constraints apply across all three. None of them has its own separately published numeric row cap; the practical limits come from the conversion tool and the submission channel, not from a filing-type-specific BIR rule.

Summary #

There is no published BIR row limit for RELIEF, SAWT, QAP, or alphalist DAT files — the file format’s requirement is structural (header, detail, trailer records built through the Alphalist Data Entry and Validation Module), not numeric. The real ceilings that make a very large Excel file a practical problem come from the conversion tool’s own per-file limits and the size of an eSubmission email attachment. When a source spreadsheet outgrows either one, split it along a real boundary — branch or TIN, month within the quarter, or document type — and regenerate each resulting DAT file from its own filtered source data so every file’s header, detail rows, and trailer count stay internally consistent. For the mechanics of what a broken trailer count actually looks like, see Excel-to-DAT File Conversion Mistakes; for the conversion basics this guide builds on, see Your First Excel to DAT Conversion and BIR DAT File Naming Convention and Folder Structure.