Converting a Payroll Export to a BIR DAT File: Common Column-Mapping Errors

A payroll system export and the BIR’s Alphalist of Employees DAT file store the same employee data in incompatible shapes, and most “conversion” failures are really mapping failures — a merged name column, a TIN still carrying dashes, or a date in the wrong field order, not bad payroll data. Getting the mapping right means matching each payroll column to the specific field the BIR’s layout expects, not just running the export through a converter and hoping the columns line up.

Why doesn’t a payroll export just convert directly into a DAT file? #

A payroll system export is built for payroll’s own purposes — one row per employee, a single “Name” column, a TIN formatted for a payslip — while the BIR’s Alphalist of Employees DAT file is built to a fixed record layout with separate fields in a specific order. The two were never designed to line up automatically. A payroll export from Sprout, PayrollHero, a generic accounting-system payroll module, or a plain CSV extract typically groups related data into fewer, wider columns for readability; the BIR’s layout does the opposite, splitting the same facts into more, narrower fields because its validation checks each field independently.

That mismatch is the actual source of most “the DAT file won’t convert” problems. The payroll data itself — gross compensation, tax withheld, employment status — is usually correct. What fails is the shape it’s in when it hits the BIR’s Alphalist Data Entry and Validation Module.

What field layout does the 1604-C Alphalist of Employees DAT file actually require? #

The Alphalist of Employees attached to BIR Form 1604-C is built from a header record and one detail record per employee, each with fields in a fixed order, fixed width, and fixed format — not a flexible column layout a converter can guess at. The header record identifies the employer and the return period; each detail record covers one employee for the full calendar year.

Each employee’s detail record then carries, at minimum, a TIN, separate last name, first name, and middle name fields, an MWE (Minimum Wage Earner) or employment-status flag, and the year’s gross compensation, taxable compensation, and tax withheld. The header structure above reflects the Alphalist DAT layout the BIR published as Annex A to RMC No. 7-2021, later revised — including the file naming convention — by RMC No. 25-2024. Confirming you’re mapping to the current version matters, since the BIR has updated the module more than once; RMC No. 15-2025, for example, rolled out Version 7.4 of the Alphalist Data Entry and Validation Module and required taxpayers who had already submitted under the older version to re-validate and resubmit.

The single field most payroll exports get wrong first is the name — because payroll systems almost always store it as one combined column, not three.

Worked example: mapping a payroll export to the alphalist DAT layout #

Meridian BPO Solutions (a fictional employer) exports its year-end payroll register to prepare the 1604-C Alphalist of Employees, and two of its rows fail validation on the first pass — not because the compensation figures are wrong, but because three columns weren’t reshaped to match the DAT layout before conversion.

Corrected mapping before regenerating the DAT file:

Splitting the name field takes an explicit step in Excel (Text to Columns on the comma, then trimming the middle initial from the first-name remainder) rather than a straight column copy. The TIN needs its hyphens stripped and its last three digits — the branch code, commonly 000 for a head office employee — moved into its own field. The date needs to be read as day/month/year and rewritten in the layout’s month/day/year order, not just reformatted on screen, since a cell that displays correctly can still hold the value in the wrong underlying order.

Other column-mapping errors that show up in payroll exports #

Beyond the name, TIN, and date errors above, a handful of other payroll-export habits commonly break alphalist mapping — each is a formatting problem in the export, not a payroll calculation error.

Where does the DAT-file requirement for the alphalist come from? #

Submitting the Alphalist of Employees as a structured file built to the BIR’s own layout — not an ad hoc payroll export — has been the standard since the BIR moved alphalist submission to its Data Entry Module. Revenue Memorandum Circular (RMC) No. 19-2015, covering FAQs on the BIR’s electronic filing platform, states the underlying requirement directly:

“…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.”

That same logic — prepared using the BIR’s own Data Entry Module, to its own field layout — carries over to the Alphalist of Employees attached to BIR Form 1604-C: the file’s structure is fixed by the layout the module produces, not by whatever a payroll system happens to export. A payroll export is a legitimate starting point for building that file, but it has to be reshaped to the layout first, not submitted as-is or hand-converted to .dat without mapping each field correctly.

Pre-conversion mapping checklist #

• Employee Name column split into separate Last Name, First Name, and Middle Name fields before mapping
• TIN stripped of hyphens and spaces, formatted as a 9-digit text value, with the branch code in its own field
• Pay-period or return-period date reformatted to the layout’s exact MM/DD/YYYY order, not just displayed that way
• Amount columns (gross compensation, taxable compensation, tax withheld) formatted as plain numbers, no currency symbol or thousands separator
• MWE or employment-status explicitly flagged per employee, not left for the converter to infer
• Gross compensation broken into its taxable and non-taxable components, not left as one combined total
• Export pulled from full-year payroll history, so resigned or terminated employees aren’t dropped
• No blank or subtotal rows left in the exported range
• Resulting DAT file re-validated through the BIR’s Alphalist Data Entry and Validation Module with a zero-error report before submission

Frequently asked questions #

Why does a payroll export need extra mapping before it becomes a BIR DAT file? #

Because a payroll system’s export and the BIR’s Alphalist DAT file layout store the same underlying facts in different shapes. A payroll export typically has one merged name column, a TIN field formatted for display, and a pay-period date in whatever order the system defaults to — while the BIR’s layout needs separate last/first/middle name fields, a clean digit-only TIN plus a separate branch code, and a fixed date format. The mapping step reshapes the export into that specific structure.

Does a merged “Last, First Middle” name column actually break the DAT file? #

Yes, if it’s mapped as a single value into a layout that expects separate last name, first name, and middle name fields. The alphalist record structure keeps these as distinct fields, so a merged string either gets rejected outright or gets parsed incorrectly — a comma or suffix in the wrong place can shift part of the last name into the first name field.

Why does a TIN that looks correct in Excel still fail the alphalist upload? #

Because the layout expects a 9-digit TIN as plain text plus a separate 4-digit branch code, not the hyphenated 123-456-789-000 format people normally write or paste. Excel can also silently convert a TIN typed into a Number-formatted cell into scientific notation or drop a leading digit, so the value can look right on screen and still export wrong.

What date format does the BIR alphalist DAT file expect? #

The header record’s return period is a date field, and payroll exports commonly default to a day-first or month-first order that doesn’t match what the layout expects. A date that displays correctly in a spreadsheet can still be stored in the wrong order underneath, which is why reformatting the period column explicitly, rather than trusting how it looks on screen, is the safer fix.

Can I just fix one bad row in an already-generated DAT file instead of re-exporting from payroll? #

It’s risky and not the recommended fix. The DAT file’s records depend on exact field order, width, and count staying in sync, so hand-editing one row in a text editor can leave the file internally inconsistent even though the one value you changed looks correct. The safer path is correcting the mapping at the source spreadsheet and regenerating the whole file.

Summary #

A payroll export and the BIR’s Alphalist of Employees DAT file store identical facts in incompatible shapes, and the mapping step — not a generic “convert to DAT” step — is where most rejections start. Split the name column into last/first/middle, strip the TIN down to nine digits with a separate branch code, reformat the return-period date to the layout’s exact order, and keep amount columns as plain numbers. Every one of those is a reshape of the source data, not a payroll correction, and regenerating the whole file after a fix beats hand-editing a generated .dat. For the broader set of validation failures once a file is generated, see Excel to BIR DAT File: The Most Common Validation Errors and How to Fix Each One; for the alphalist-specific error patterns beyond column mapping, see Common 1604-C Alphalist of Employees Errors and How to Fix Them Before Filing.

The Alphalist of Employees module referenced above is in development. QAP, SAWT, RELIEF, and BIR Form 2307 are live today, free.

Sources #

Primary source

• BIR — Revenue Memorandum Circular No. 19-2015, FAQs on the electronic filing and payment platform requiring SAWT/MAP alphalist data to be prepared using the BIR’s Data Entry Module and submitted to esubmission@bir.gov.ph

Secondary sources

• Sprout Solutions — How to Submit BIR Form 1604-C and Alphalist — payroll-to-alphalist filing workflow
• Forvis Mazars Philippines — BIR RMC 25-2024 tax alert — confirms RMC No. 25-2024 revised the alphalist file structures and naming convention in Annexes A and B
• KPMG Philippines — RMC No. 7-2021 Annex A field layout — header record field names, widths, and formats for the alphalist DAT file