BIR DAT File Guide for the Philippines

Sooner or later, BIR compliance stops being about filling in a form and starts being about producing a file. A .DAT file is the machine-readable format the BIR uses to ingest your periodic summaries — your list of sales and purchases, your list of payees, your alphalist of withholding. It isn't a return you eyeball; it's a strictly-structured data file the BIR's tools either accept or reject. This guide explains what DAT files are, which submissions use them, how they're validated and sent, the error classes that trip people up, and why one clean set of books makes all of them come out the same.

The short answer

A BIR .DAT file is how the Bureau receives bulk, line-by-line data it would never want typed into a form — every sale and purchase, every payee you withheld from, every entry in an alphalist. You generate the file with the BIR's offline data-entry tool (or software that writes the same layout), run it through the validation module to confirm the structure is correct, and then submit it through the BIR's electronic channels. Get the books right and the file is just an export; get the books wrong and the validator will tell you — usually in a message that's terse and exact.

Who this guide is for

• Business owners who've been asked to submit an SLSP, QAP, or alphalist and have never produced a DAT file before.
• Freelancers and professionals who file a SAWT to claim their withholding credits and keep hitting validation errors.
• Bookkeepers and accountants who assemble these files for clients and want a clean pipeline instead of a re-keying scramble.

What a DAT file actually is

Think of a .dat file as a tightly-formatted text file that encodes rows of data in a layout the BIR's systems can parse automatically. It isn't meant to be read or edited by hand — open one in a text editor and you'll see delimited fields, header and detail records, and control totals, not a friendly form. The BIR defines the exact structure for each submission type, and the matching offline tool writes that structure for you so you don't have to. The whole point is machine ingestion: instead of someone re-typing your hundreds of invoices into a portal, the BIR loads your file directly. For the underlying idea in more depth, see BIR DAT files explained.

Because the format is rigid, a DAT file is valid or it isn't — there's little middle ground. That's a feature: it forces the data to be complete and internally consistent before the BIR will accept it.

Which submissions use DAT files

DAT files show up across VAT and withholding compliance. The big four:

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

Different submissions, same idea — each is a structured list the BIR ingests as a DAT file rather than a hand-typed form. Note that DAT files are for these summaries and lists; the e-filing returns themselves (the VAT and withholding forms) generally go in as XML, a separate pipeline covered in the BIR XML filing guide.

How a DAT file gets built, validated, and submitted

The lifecycle is the same regardless of which summary you're filing: you assemble the data, encode it into the DAT layout, prove it's structurally sound, and then transmit it.

1. 1

   Assemble the data

   Gather the period's transactions — sales, purchases, or payees — from your books, with the supporting details (names, TINs, amounts) each submission needs.

2. 2

   Encode into the DAT layout

   Enter the data in the BIR's offline data-entry tool for that submission, or generate the file directly from software that writes the same layout, so you skip the re-keying.

3. 3

   Run the validation module

   Pass the file through the BIR's validation tool. It checks structure, required fields, and reference data and either certifies the file or lists the errors.

4. 4

   Fix and re-validate

   Correct anything the validator flags — most fixes are at the source (a wrong TIN, a mismatched total) — and re-run until the file passes cleanly.

5. 5

   Submit through the BIR's channel

   Transmit the validated file through the BIR's prescribed electronic submission channel for that file type, and keep the confirmation.

6. 6

   Archive the file and proof

   Retain the validated DAT file and the submission acknowledgement with your records, so you can reproduce exactly what you sent.

Common error classes

DAT rejections look intimidating but almost always fall into a few buckets. Knowing the bucket tells you where to fix it — and the fix is usually in your data, not the file:

SLSP files have their own recurring pitfalls — see common SLSP DAT file errors for the ones that surface most. The pattern holds across all of them: a validator error is a symptom; the cure is clean, consistent source data.

How this connects to your books

Here's the quiet truth about DAT files: the file is the easy part. The hard part is that the data inside it has to match your books, your certificates, and your returns. When your transactions live in a real double-entry ledger — each sale split into net and output VAT, each withheld payment carrying its payee and ATC — every DAT file is just a different view of the same posted entries. The SLSP is your sales and purchases; the QAP and alphalist are your withholding; the SAWT is your claimed credits. Build them from one source and they can't disagree. Reconstruct each one separately in a spreadsheet and you've signed up for a reconciliation problem every period — which is precisely what the validator (and later the BIR's cross-checks) will surface.

Common mistakes

• Hand-editing a DAT file. The layout is exact; opening one in a text editor to 'just fix a number' usually corrupts it. Fix the source and re-generate.
• Using an outdated tool version. The BIR updates its offline and validation tools; an old version can produce a file the current channel rejects.
• Dirty master data. A single wrong or missing TIN can fail an otherwise-perfect file — keep your customer, supplier, and payee records clean.
• Rebuilding each summary separately. Re-keying the SLSP, QAP, and alphalist by hand guarantees they'll drift apart and mismatch each other.
• Not keeping the validated file and acknowledgement. If you can't reproduce exactly what you submitted, you can't defend it later.