Free tool
Check your BIR alphalist before BIR does.
Drop in a .DAT file and get the same findings BIR's desktop validator would give you — plus the line number, the column and the fix, which it won't. No sign-up, no upload, no Windows.
Drop your .DAT file here
Alphalist files for 1600-VT, 1600-PT, 1601-EQ, 1601-FQ, 1621, SAWT, 1604-C, 1604-E and 1604-F, plus RELIEF SLSP.
Your file never leaves your browser
Coverage
Every alphalist form, plus SLSP.
| 1604-C | Annual alphalist of employees |
|---|---|
| 1604-E | Annual alphalist of payees, expanded |
| 1604-F | Annual alphalist of payees, final tax |
| 1601-EQ | Quarterly alphalist of payees (QAP) |
| 1601-FQ | Quarterly alphalist, final tax |
| 1600-VT | Monthly alphalist of payees, VAT |
| 1600-PT | Monthly alphalist, percentage tax |
| 1621 | Quarterly alphalist of payees |
| SAWT | Summary alphalist of withholding taxes |
| SLSP | RELIEF sales and purchases |
Rules are reproduced from Alphalist Data Entry and Validation 7.4 — its record layouts, its 481 error messages, and its 549-code ATC table. SLSP is the exception: BIR ships no validator for it, so those checks come from our own RELIEF writer and are structural only.
Questions
Before you ask.
- Does my file get uploaded anywhere?
- No. The file is read and checked by code running inside your browser tab. There is no upload, no server, and no copy kept. You can disconnect from the internet after the page loads and it will still work.
- Why does BIR's tool report errors that make no sense?
- Usually because a value contains a comma. The format has no escape mechanism — FoxPro's importer does not honour commas inside quoted fields — so a payee written as "GARCIA, JR" splits into two columns and shifts every column after it by one. The period then lands in the ATC column, the ATC in the rate column, and BIR's tool reports a handful of unrelated-looking errors without ever mentioning the comma. We report the comma and skip the consequences.
- Is this the same as BIR's validator?
- It reproduces the rules of Alphalist Data Entry and Validation 7.4, the desktop tool — the same column layouts, the same field checks, the same ±2.00 tolerance on control totals, and the same error messages. It is not BIR's eSubmission, which runs its own server-side checks nobody outside BIR can see. A clean result here is necessary but not sufficient.
- My file passes here but BIR's tool rejects it. Why?
- Most often it is the 1604-C control record. BIR's own writer emits 36 columns for C1 and 45 for C2, but BIR's own validator only accepts 35 and 43 — so a correctly generated 1604-C fails its own validator. We flag that as a warning rather than an error and explain both sides. If you hit something else, send us the file's report.
- Why does a name with an ampersand fail?
- The validator rejects "&" in names, but BIR's writer does not strip it — so "SMITH & SONS" comes out of data entry and then fails validation. Write it as "SMITH AND SONS".
- What about accented letters?
- The format is single-byte Windows-1252 and the name check rejects anything outside printable ASCII, so PEÑA has to reach the file as PENA. We read your file as Windows-1252 rather than UTF-8, which is why we can tell you which character is the problem instead of showing a replacement symbol.
Or stop generating broken files in the first place.
CPAlly keeps your books and produces the alphalist from them — TINs already validated, names already stripped of the characters BIR rejects, control totals that match because they come from the same ledger.