Can You Just Rename an Excel File to .DAT for BIR eSubmission? Why It Doesn't Work

No — renaming a file from .xlsx to .dat does not create a valid BIR DAT file. A DAT file is a plain-text file with a fixed field layout that the BIR’s Data Entry and Validation Module produces; an Excel workbook is a completely different binary/XML format inside. Changing the extension changes only the file’s name, not its content, so the BIR’s eSubmission system will reject it or fail to read it correctly.

This is one of the most common first-time mistakes when preparing RELIEF SLSP, QAP, SAWT, or annual alphalist submissions. This guide explains what’s actually inside a BIR DAT file, why a renamed spreadsheet fails, and how to convert your data correctly the first time.

Why doesn’t renaming a file change its format? #

A file extension is just a label — it tells your operating system which program to open the file with, but it doesn’t change a single byte of the file’s actual content. An .xlsx file is technically a ZIP-compressed package of XML documents describing rows, columns, formulas, and formatting. When you rename it to .dat, the file is still that same ZIP/XML package; it just has a different name.

The BIR’s systems don’t look at your file’s extension to decide how to read it — they parse the file’s actual bytes, expecting a specific plain-text structure. Feed them a renamed spreadsheet and one of two things happens: the Data Entry and Validation Module refuses to open it because the content isn’t plain text in the expected layout, or — if it slips through partially — the fields come out garbled or misaligned once someone (or some downstream process) tries to parse it as delimited text.

This is the same reason you can’t rename a .jpg photo to .pdf and expect a PDF reader to open it. The extension is a hint, not a transformation.

What does a real BIR DAT file actually contain? #

A genuine BIR DAT file is a plain-text file where every line represents one structured record — one payee, one sale, or one purchase — with each field separated by a fixed delimiter and formatted exactly the way the BIR’s own data entry programs expect. That means specific date formats, TINs entered as fixed-length digit strings (no dashes), and peso amounts written as plain numbers with no ₱ symbol, no thousands separators, and a fixed number of decimal places.

Historically, the BIR built and distributed its own Data Entry and Validation Module applications for RELIEF, Alphalist, and related submissions specifically so taxpayers wouldn’t have to construct this layout by hand — you enter or import your data into the BIR’s own program, and it writes out the .dat file in the exact structure its back-end systems expect. The naming convention for the file itself is also prescribed — see BIR DAT File Naming Convention and Folder Structure for how the BIR expects the filename (not just the content) to be built from your TIN and the covered period.

Some of the structural details a spreadsheet export routinely gets wrong without a purpose-built converter:

• Field order and count — a DAT file expects an exact number of fields per line, in an exact sequence; an extra or missing column silently shifts every field after it.
• Fixed delimiters — records are split by a specific character (commonly a pipe or comma depending on the submission type), not by however Excel happens to export a CSV in your regional settings.
• TIN formatting — a nine-to-twelve-digit numeric string with no hyphens, not the 123-456-789-000 format most people type into a spreadsheet.
• Date formats — a specific numeric date pattern, not whatever date format your Excel locale defaults to.
• No formatting artifacts — no currency symbols, no thousands separators, no merged cells, no trailing whitespace.

The BIR has always required a structured data file, not a document #

The requirement for a specific, structured file — not a spreadsheet, PDF, or paper listing — predates DAT-based eSubmission itself. Revenue Regulations No. 1-2012, which made quarterly Summary List of Sales and Purchases submission mandatory for all VAT-registered taxpayers, amended the earlier storage-medium language in RR No. 16-2005:

Every reference to “magnetic form 3.5-inch floppy diskettes” in Revenue Regulations No. 16-2005 shall now refer to “Compact Disk-Recordable (CDR).”

The physical medium changed — floppy diskette, then CD-R, now direct upload through eSubmission — but the underlying requirement never did: a data file built to the BIR’s exact field structure. Renaming a spreadsheet skips that structure entirely, which is why it has never been a valid substitute under any of these submission methods.

Why can’t the BIR just accept a CSV export instead? #

A CSV file and a BIR DAT file are both plain text, but “plain text” alone isn’t enough — the BIR’s back-end systems need every submitted file, from every taxpayer nationwide, to follow one identical field layout so they can be parsed automatically at volume. Excel’s default CSV export doesn’t enforce fixed field widths, doesn’t guarantee TINs stay as text instead of being auto-converted to scientific notation, and varies by regional settings (comma vs. semicolon separators, date order, decimal symbols).

A DAT file removes that ambiguity: the format is fixed regardless of what software or locale produced it, as long as the fields were built to the BIR’s specification. That predictability is what lets millions of RELIEF, QAP, SAWT, and alphalist records get validated and loaded without manual review of each file.

How to actually convert Excel data into a valid DAT file #

Skip the rename shortcut and use a tool built to map your spreadsheet columns into the BIR’s exact DAT structure, or the BIR’s own Data Entry and Validation Module. Either path does the same underlying job: reading your data field by field and re-writing it in the fixed layout the BIR expects, rather than repackaging the spreadsheet as-is.

1. Keep your source data in Excel with clear column headers (TIN, name, amounts, ATC, period) — this is your working copy, not the submission file.
2. Import that data into a converter built specifically for the return type you’re filing (RELIEF, QAP, SAWT, or alphalist), so it can map each column to the correct DAT field, format, and delimiter.
3. Generate the .dat file from the tool — don’t create it by saving Excel as “Other file type” and manually changing the extension afterward.
4. Validate the generated file, either through the BIR’s own validation module or your converter’s built-in check, before naming it per the BIR’s convention and submitting it through eSubmission.
5. Keep the original Excel workbook as your internal record — the DAT file is a derived submission artifact, not something you edit directly.

BIR Online Tools builds the DAT file directly from your Excel data using the BIR’s field specifications, so there’s no manual renaming step and no guessing at delimiters or date formats.

Frequently asked questions #

Can I rename my Excel file from .xlsx to .dat and submit it to the BIR? #

No. Changing a file’s extension does not change its internal structure. An .xlsx file is a compressed XML package; a BIR DAT file is a plain-text file with fixed-width or delimited fields in the exact layout the BIR’s Data Entry and Validation Module produces. The BIR’s eSubmission system reads the file’s actual content, not its extension, so a renamed spreadsheet fails validation or is silently unreadable.

What is actually inside a real BIR DAT file? #

A BIR DAT file is a plain-text file where each line is one record (one payee, one sale, or one purchase), with fields separated by a fixed delimiter and arranged in the exact column order and format the BIR’s RELIEF, QAP, SAWT, or Alphalist Data Entry Module expects — including specific date formats, fixed-length TIN fields, and numeric fields without currency symbols or thousands separators.

Why does the BIR require a DAT file instead of just accepting an Excel or CSV file? #

The DAT format lets the BIR’s back-end systems parse millions of submitted records with one fixed, predictable structure across every taxpayer, without depending on Excel’s variable formatting, formulas, merged cells, or locale-specific number formats — all of which can silently corrupt a plain CSV export.

What’s the correct way to turn my Excel workbook into a valid BIR DAT file? #

Enter or import your data into the BIR’s own Data Entry and Validation Module for the return type (RELIEF, QAP, SAWT, or Alphalist), or use a converter tool built specifically to map your Excel columns into the BIR’s exact DAT layout and generate the file in that format directly — not by exporting or renaming a spreadsheet.

Will the BIR eSubmission system tell me my file is invalid, or will it just fail silently? #

Behavior varies by validation point. The BIR’s own Data Entry and Validation Module typically raises a validation error on import if a file’s structure doesn’t match. If a malformed or renamed file gets past that stage and is emailed directly to the BIR’s eSubmission address, it risks being rejected or misread downstream, which is why validating the file before submission is worth doing every time.

Summary #

A .dat extension on an Excel file is cosmetic — the BIR’s eSubmission system parses file content, not filenames, and a renamed spreadsheet doesn’t have the fixed-delimiter, fixed-field structure a real DAT file needs. Build the file with the BIR’s Data Entry and Validation Module or a converter designed around the BIR’s field specification, validate it, then name and submit it correctly. For the full picture of the format itself, see What Is a BIR DAT File?, and for the submission process, see What Is the BIR eSubmission System?