BIR DAT File vs CSV File: Which Format Does Each BIR System Actually Require?
No — a .csv file and a BIR .dat file are not interchangeable, even though both are plain text. The BIR’s eSubmission system for RELIEF, SAWT, QAP, and annual Alphalist filings requires the specific DAT structure its own Data Entry and Validation Module produces, not a generic comma-separated export from Excel or Google Sheets.
This guide explains what actually separates the two formats, why a CSV export can silently fail the BIR’s requirements even when the underlying data looks correct, and how the BIR’s format requirements differ across its various electronic systems.
Convert Your Excel Data Into a Real BIR DAT File FREE →What DAT and CSV actually have in common #
Both formats are plain text, and both organize data into rows where each row is one record. That surface similarity is exactly why the two get confused: open either one in a text editor and you’ll see readable lines of comma- or pipe-separated values, not a binary format like a .xlsx workbook.
That’s where the similarity ends. A CSV file’s exact structure is whatever the exporting program happened to produce — Excel, Google Sheets, and accounting software each handle CSV export slightly differently. A BIR DAT file’s structure is not left to the exporting tool at all; it’s a fixed specification the BIR’s own systems expect every submission to match.
Where DAT and CSV actually diverge #
A DAT file built for BIR eSubmission enforces details a generic CSV export doesn’t guarantee:
| Element | Generic CSV export | BIR DAT file |
|---|---|---|
| Field order | Whatever column order your spreadsheet happened to have | Fixed order per the BIR’s field specification for that return type |
| Delimiter | Comma by default, but varies by regional settings (some locales default to semicolon) | Fixed delimiter as the BIR’s module expects |
| TIN formatting | Prone to being auto-converted to scientific notation or losing leading digits as a “number” | Fixed-length digit string, entered as text |
| Date formatting | Follows Excel’s regional date format | Fixed numeric date pattern regardless of locale |
| Decimal/currency formatting | May include ₱ symbols, thousands separators, or locale-specific decimal commas | Plain numeric value, no symbols or separators |
| Structural validation | None — Excel will export whatever is in the sheet, errors and all | Checked by the BIR’s own Data Entry and Validation Module before a file is considered valid |
A CSV file containing the same underlying data as a valid DAT file can still fail eSubmission if any one of these details doesn’t match — which is why “just export as CSV” isn’t a safe substitute for generating an actual DAT file. For the closely related mistake of simply renaming a file instead of building it correctly, see Can You Just Rename an Excel File to .DAT?
Where the DAT requirement itself comes from #
The requirement to use the BIR’s own Data Entry Module output — not just any delimited text file — is documented guidance dating back to the BIR’s early eSubmission FAQs. Revenue Memorandum Circular (RMC) No. 19-2015, covering FAQs on the electronic platform for filing tax returns, describes the process 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.”
“Prepared using the Data Entry Module” is doing real work in that sentence — it’s the BIR’s own program generating the file, not a spreadsheet export approximating the same layout.
Not every BIR system even wants the same format #
DAT files aren’t a universal BIR requirement — they’re specific to the eSubmission channel used for RELIEF, SAWT, QAP, and Alphalist filings. Other BIR electronic systems have their own separate technical requirements entirely:
- eSubmission (RELIEF, SAWT, QAP, Alphalist) — expects DAT files, emailed to esubmission@bir.gov.ph
- eAFS (audited financial statement attachments) — accepts PDF file uploads through its own portal, not DAT or CSV
- EIS (electronic invoicing for covered large taxpayers) — uses its own separate data transmission requirements distinct from the eSubmission DAT workflow
Assuming one BIR system’s file format requirement applies to another is a separate, common source of confusion from the DAT-vs-CSV question — each system’s technical requirements should be confirmed on its own terms rather than assumed to match a different filing you’ve done before.
How to avoid the DAT-vs-CSV mismatch #
Treat “export as CSV” and “generate a BIR DAT file” as two different actions, not two names for the same step. The safest path is to build the DAT file directly from your source data using a tool that already knows the BIR’s field specification for your return type, rather than exporting a CSV and hoping it happens to match.
- Keep your working data in Excel with clear, complete columns.
- Use the BIR’s own Data Entry and Validation Module, or a converter purpose-built for the return type (RELIEF, QAP, SAWT, or Alphalist), to generate the DAT file directly.
- Validate the generated file before naming and submitting it — see How to Validate a BIR DAT File Before eSubmission.
- If you’re preparing an eAFS or EIS submission instead, confirm that system’s own format requirements rather than assuming the DAT workflow applies.
Frequently asked questions #
What’s the difference between a DAT file and a CSV file? #
Both are plain-text formats where data is organized into rows and fields, but a CSV file’s structure is defined loosely by whatever program exports it (commas, your regional date and number formats), while a BIR DAT file follows a fixed field layout, delimiter, and formatting the BIR’s Data Entry and Validation Module specifically produces for a given return type.
Can I just save my Excel file as CSV and submit that to the BIR instead of a DAT file? #
Not reliably. A generic CSV export doesn’t enforce the BIR’s exact field order, fixed TIN formatting, or date/amount formatting, and Excel’s own CSV export behavior varies by regional settings — such as auto-converting long TINs to scientific notation. The BIR’s eSubmission system for RELIEF, SAWT, QAP, and Alphalist expects the DAT structure specifically, not a generic CSV.
Do all BIR electronic systems use the same DAT file format? #
No. RELIEF, SAWT, QAP, and annual Alphalist submissions through eSubmission use the DAT format. Other BIR systems use entirely different formats and channels — the eAFS system for financial statement attachments accepts PDF files, not DAT or CSV, and other systems have their own separate technical requirements.
Why does the BIR use a specialized DAT format instead of a common format like CSV or Excel? #
A fixed, purpose-built format lets the BIR’s back-end systems parse submissions from every taxpayer nationwide the same predictable way, without depending on the varying default behaviors of spreadsheet software across different versions, regional settings, and export options.
How do I know if my file is in the correct DAT format before I submit it? #
Run it through the BIR’s own Data Entry and Validation Module for the return type, or a converter tool built around the BIR’s field specification, before emailing it to esubmission@bir.gov.ph. Validating first catches structural mismatches before they become a rejected or delayed submission.
Summary #
A CSV export and a BIR DAT file are both plain text, but only one of them is built to the BIR’s exact field specification for RELIEF, SAWT, QAP, and Alphalist eSubmission — and each BIR electronic system (eSubmission, eAFS, EIS) has its own separate format requirement besides. Build your DAT file with a tool designed around the BIR’s actual field layout, and validate it before you submit. For the format itself, see What Is a BIR DAT File?, and for naming and packaging once the file is valid, see BIR DAT File Naming Convention and Folder Structure.