BIR DAT Files Explained for Filipino Businesses

The first time someone tells you to submit a DAT file, it can sound like jargon from a different decade. It isn't complicated, though — a .DAT file is just the format the BIR uses to receive lists of data too long to type into a form: every sale and purchase, every person you withheld tax from, every employee on your payroll. Instead of keying hundreds of rows into a website, you hand the BIR one structured file and its systems read the whole thing automatically. This explainer walks through what a DAT file actually is, why the BIR works this way, which submissions use them, how they get made and checked, and why building one by hand tends to go wrong.

The short answer

A .DAT file is a strictly-structured text file that encodes rows of data in a layout the BIR's computers can read automatically. It's used for submissions that are lists — sales and purchases, payees, employees — where typing each row into a portal would be absurd. You don't write the file by hand; you use the BIR's offline data-entry tool (or software that produces the same layout) to generate it, run it through the BIR's validation module to confirm the structure is correct, and then submit it through the BIR's electronic channel. The file either passes validation or it doesn't — there's no 'mostly right'.

Who this guide is for

• New business owners who've just been told to submit a DAT file and want to understand what it is before touching a tool.
• Freelancers and professionals filing their first SAWT and wondering why it isn't just a form.
• Anyone moving off spreadsheets who wants to understand the file the BIR actually expects at the end of the pipeline.

What a DAT file actually is

Picture a .dat file as a very disciplined text file. Open one in a plain text editor and you won't see a form with labels and boxes — you'll see rows of values separated by delimiters, with a header record that identifies the taxpayer and the period, detail records for each line of data, and control totals that sum the detail. It isn't meant to be read or edited by a person; it's meant to be read by a machine. The BIR publishes the exact structure for each kind of submission, and the matching offline tool writes that structure for you so you never have to format it yourself.

It helps to know what a DAT file isn't. It isn't a PDF you print and mail. It isn't a form you fill in on a website. And it isn't the same as the XML the BIR uses for the e-filing returns themselves — that's a separate format and a separate pipeline (covered in the BIR XML filing guide). DAT files carry the lists and summaries; XML generally carries the returns.

Why the BIR uses DAT files

The reason is volume and verification. A VAT business can have thousands of sales and purchases a quarter; an employer can have hundreds of staff. Typing all of that into a web form would be slow and riddled with keystroke errors — and impossible for the BIR to cross-check at scale. A structured DAT file solves both problems: your data goes in once, as a file, and the BIR's systems can automatically match it against returns, against the certificates you issued, and against what other taxpayers reported about you. The rigid format is the point — it forces the data to be complete and consistent before the BIR will accept it.

Which submissions use DAT files

DAT files appear across VAT and withholding compliance. The ones you're most likely to meet:

• SLSP — Summary List of Sales and Purchases. A VAT taxpayer's line-by-line list of sales and purchases. See the SLSP guide.
• SAWT — Summary Alphalist of Withholding Taxes. A payee's list of the creditable-withholding certificates they're claiming.
• QAP — Quarterly Alphalist of Payees. A withholding agent's quarterly list of everyone they withheld from. See the QAP guide.
• Alphalist. The year-end consolidated roll-up of payees and employees. See the alphalist guide.

Different names, same idea — each is a list the BIR ingests as a file rather than a form. They share the same lifecycle, the same kinds of validation, and the same dependence on clean underlying data.

How a DAT file gets made and checked

1. 1

   Gather the data

   Pull the period's transactions or people — with the names, TINs, and amounts the submission needs — from your records.

2. 2

   Encode it into the DAT layout

   Enter the data in the BIR's offline tool for that submission, or generate the file directly from software that writes the same layout.

3. 3

   Validate the file

   Run it through the BIR's validation module. It checks the structure, required fields, and reference data, then certifies the file or lists what's wrong.

4. 4

   Fix and re-validate

   Correct anything flagged — usually at the source data, like a wrong TIN or a total that doesn't foot — and validate again until it passes.

5. 5

   Submit and keep proof

   Transmit the validated file through the BIR's channel, then keep the file and the acknowledgement so you can reproduce exactly what you sent.

Why doing it by hand is error-prone

The trouble with building a DAT file from scratch every period is that two things have to be perfect at once: the structure (exactly the right layout, the right tool version, every required field present) and the data (valid TINs, correct names, detail rows that foot to the control totals, the right period and taxpayer). Re-keying a quarter's transactions into the offline tool, or stitching the list together from spreadsheets and emailed certificates, gives errors plenty of places to creep in — a transposed TIN, a name that doesn't match the BIR's registration, a total that's off by one rounding decision. The validator catches many of these, but only after you've done the work, and each round trip is time you don't have at the deadline. Worse, if you rebuild the SLSP, the QAP, and the alphalist separately, they tend to drift apart and contradict each other — and the BIR's cross-checks notice. For the specific failures that bite, see common SLSP DAT file errors.

How this connects to your books

The most reliable way to produce a clean DAT file is to never assemble one — to generate it from books that already hold the data. When your sales, purchases, and withholding live in a real double-entry ledger, each entry already carries the names, TINs, amounts, and tax that a DAT file needs. The SLSP is then just a view of your sales and purchases; the QAP and alphalist are views of your withholding; the SAWT is your claimed credits. They come from one source, so they foot to your returns and agree with each other automatically — which is exactly the consistency the validator is checking for. The file stops being a quarterly construction project and becomes an export.

Common mistakes

• Opening a DAT file to hand-edit a number. The layout is exact — editing the file directly usually corrupts it. Fix the source and re-generate.
• Using an outdated offline or validation tool. An old version can produce a file the current channel rejects; use the current tools from BIR eServices.
• Dirty master data. One wrong or missing TIN can fail an otherwise-perfect file; keep customer, supplier, and payee records clean.
• Confusing DAT with XML. Lists go in as DAT, returns generally as XML — sending the wrong format for the submission won't work.
• Not keeping the validated file and acknowledgement. If you can't reproduce what you submitted, you can't defend it later.