What does a duplicate TIN or duplicate record error actually mean in a BIR DAT file?

It means the Alphalist Data Entry and Validation Module found two rows in your RELIEF, SAWT, or QAP file that it treats as the same record — most often because the same payee TIN and ATC combination appears twice, or because two different payees were accidentally given the identical TIN through a typo or a copy-paste error.

Is a duplicate TIN error the same as a duplicate record error?

Not exactly, though BIR Online Tools' error wording for both conditions on these DAT files centers on the TIN field. A duplicate record error usually means the whole row — TIN, ATC, and period — repeats; a duplicate TIN error can also fire when one payee's TIN was mistakenly copied onto a different payee's row, which is a data-accuracy problem even though the file is technically still internally consistent.

Why does my DAT file show a duplicate TIN when I only entered each supplier once?

The most common cause is a spreadsheet copy-paste that dragged a formula or a pasted value down past the last real row, duplicating the last supplier's TIN into a blank-looking row that still has an amount in another column. Filtering the TIN column for duplicates in Excel usually surfaces it immediately.

Can I just delete one of the duplicate rows and resubmit?

Only after confirming which row is the error. If it is a true duplicate of the same transaction, delete the extra row. If two different payees share a TIN because one was mistyped, correct the wrong TIN instead of deleting either row — deleting a row that represents a real, separate payment would understate your RELIEF, SAWT, or QAP totals.

Does the BIR's Validation Module reject the whole file over one duplicate row?

Yes. The Alphalist Data Entry and Validation Module validates the file as a whole before it can be submitted through eSubmission, so a single duplicate TIN or record among hundreds of rows is enough to block the entire RELIEF, SAWT, or QAP file, not just that one line.

Duplicate TIN or Record Error When Uploading a BIR DAT File: Causes and Fixes

A duplicate TIN or duplicate record error in a BIR DAT file means the Alphalist Data Entry and Validation Module found two rows it reads as the same entry — usually because one payee’s row was pasted twice, or because a typo gave two different payees the identical Taxpayer Identification Number. Either way, the Module blocks the entire RELIEF, SAWT, or QAP file from passing validation until the conflicting row is found and corrected in the source spreadsheet, not patched inside the DAT file itself.

This guide covers the two different root causes behind this error, how to isolate the offending row in Excel, and why fixing it in the DAT file directly is the wrong approach. For the broader validation picture, see How to Validate a BIR DAT File Before eSubmission; for what to do about a specific payee TIN, see What to Do When a Payee Gives You a Wrong or Missing TIN.

Catch Duplicate Rows Before You File FREE →

Why does the Validation Module treat a TIN as a duplicate? #

The BIR’s Alphalist Data Entry and Validation Module is built around the assumption that every Taxpayer Identification Number uniquely identifies one person or entity, so when it encounters the same TIN twice under conditions it reads as a repeat — the same ATC, the same period, often the same amount — it flags the file rather than guessing which row is correct. That assumption traces directly to how a TIN is supposed to function under Philippine tax law.

Section 236(j) of the National Internal Revenue Code (NIRC) is the basis for every TIN field on every BIR form, DAT file, and return:

“Any person required under the authority of this Code to make, render or file a return, statement or other document shall be supplied with or assigned a Taxpayer Identification Number (TIN) which he shall indicate in such return, statement or document filed with the Bureau of Internal Revenue.”
— National Internal Revenue Code of 1997, Section 236(j)

Because the TIN is meant to be a unique identifier assigned once per taxpayer, a validation module that sees it repeated on two rows of the same alphalist has no way to know, on its own, whether that repetition is a genuine duplicate transaction or a data-entry mistake — so it rejects the file and leaves that judgment to the preparer.

What actually causes a duplicate TIN or record error? #

There are two distinct causes behind the same error message, and they need opposite fixes — deleting a row corrects one, while the other needs the TIN itself corrected, not removed.

Root cause	What it looks like in Excel	Correct fix
True duplicate row — the same payee, ATC, and payment accidentally entered or pasted twice	Two rows with identical TIN, name, ATC, and amount	Delete the extra row; keep the single correct entry
TIN collision — two different payees, but one’s TIN was mistyped to match another’s	Two rows with the same TIN but different payee names or amounts	Correct the mistyped TIN on the wrong row; keep both rows
Dragged formula or paste-down — a spreadsheet fill or paste extended past the last real row	A blank-looking extra row carrying the last payee’s TIN with no new name, or a stray amount	Delete the phantom row entirely
Split invoice, single payee, single period — the same payee paid twice in the same month under the same ATC	Two legitimate rows with the same TIN and ATC but different amounts	Usually not an error — consolidate into one row with the combined amount if your RELIEF/SAWT/QAP format expects one line per payee per period

The fastest way to tell which situation you have is to sort or filter the TIN column in your source spreadsheet for duplicates before you ever generate the DAT file — Excel’s conditional formatting “Highlight Duplicate Values” rule on the TIN column surfaces every candidate row in seconds, and comparing the payee names and amounts on each flagged pair tells you immediately whether you’re looking at a true duplicate, a collision, or a legitimate split entry that needs consolidating.

Worked example: a RELIEF SLSP file with a pasted-down TIN #

Mindanao Hardware & Trading Corp., a VAT-registered RELIEF SLSP filer, prepares its quarterly Summary List of Purchases from an Excel export of its accounts payable ledger. The bookkeeper pastes 140 supplier rows into the template, then manually adds two late invoices at the bottom by copying the last row’s format and overtyping the values.

Row	TIN	Supplier	Purchase amount
140	123-456-789-000	Davao Steel Supply	₱185,400.00
141	123-456-789-000	(blank — formatting copied but TIN not overtyped)	₱62,000.00
142	987-654-321-000	Cagayan Cement Depot	₱210,000.00

Row 141 is a late invoice from a different supplier, but the bookkeeper copied row 140’s formatting to create it and forgot to overtype the TIN field before entering the new amount. The result is a duplicate TIN that the Alphalist Validation Module flags the moment the file is checked — not because the company made the same purchase twice, but because one cell in a new row was never updated. Filtering the TIN column for duplicates immediately shows rows 140 and 141 sharing one TIN with two different amounts, which is the collision pattern, not the true-duplicate pattern — the fix is to enter the correct TIN for the actual late-invoice supplier on row 141, not to delete either row.

Summary #

A duplicate TIN or record error in a RELIEF, SAWT, or QAP DAT file always traces back to the source spreadsheet, not the DAT file itself — the Alphalist Data Entry and Validation Module flags it because a Taxpayer Identification Number under NIRC Section 236(j) is supposed to identify exactly one payee per row, and two rows sharing one TIN break that assumption. Filter the TIN column for duplicates before converting to DAT, confirm whether you’re looking at a true repeat or a mistyped collision, and fix the source data — never hand-edit the generated DAT file — before resubmitting through eSubmission.