SAWT DAT File Rejected for Duplicate TIN-ATC Combination: How to Fix It

A SAWT DAT file rejected for a duplicate TIN-ATC combination has two or more detail rows that share the same payor TIN and the same Alphanumeric Tax Code (ATC) for the period. The BIR’s Alphalist Data Entry and Validation Module expects one consolidated row per payor-TIN-and-ATC pair per period, not a separate row for every BIR Form 2307 certificate you happen to be holding from that payor under that code. The fix is to total the income payment and tax withheld across the duplicate rows and replace them with a single combined row.

This is a different failure from a row that simply has a malformed field — the data in each row may be perfectly valid on its own, but the file still fails because the same key (payor TIN + ATC) appears twice. For the broader list of SAWT validation failures, see Common SAWT DAT File Errors and How to Fix Them; for the definition and legal basis of SAWT itself, see What Is SAWT?.

What does “duplicate TIN-ATC combination” actually mean in a SAWT file? #

Every SAWT detail row is keyed by three things: the payor’s TIN, the ATC on the certificate, and the period the SAWT covers. When a validation report flags a duplicate TIN-ATC combination, it means two rows in the same file carry the identical payor TIN and the identical ATC — the module treats that pairing as one reportable entry per period, so a second row with the same key is read as a conflicting duplicate rather than a second, separate transaction.

This almost always traces back to how the file was built rather than to the certificates themselves. A payee who received more than one BIR Form 2307 certificate from the same payor in the same quarter, under the same ATC — for example, two invoices billed and withheld separately in one quarter — has two certificates that are both completely valid. The mistake is transcribing each certificate as its own SAWT row instead of combining them into one row before the DAT file is generated.

Why does the Alphalist module enforce one row per payor-ATC pair? #

The BIR’s Alphalist Data Entry and Validation Module is the same engine behind the Monthly/Annual Alphalist of Payees, and it was built around strict, non-arbitrary per-payee reporting after Revenue Regulations (RR) No. 1-2014 amended Section 2.83.3 of RR No. 10-2008. That amendment tightened what counts as an acceptable alphalist entry and made non-conforming files unusable as support for a deduction or credit claim.

Tax advisory commentary on that amendment describes the operative change this way:

“the submission of alphalist where the income payments and taxes withheld are lumped into one single amount (e.g., ‘various employees,’ ‘various payees,’ ‘PCD nominees,’ ‘others,’ etc.) is not allowed… [and] shall be deemed as not received and shall not qualify as deductible expense for income tax purposes.”

That provision addresses the opposite extreme — collapsing different payees into one vague catch-all line, which RR No. 1-2014 bars outright. But it illustrates the same underlying design choice that produces the duplicate-TIN-ATC rejection: the module expects exactly one line per reportable combination, no more and no fewer. Lumping different payors together is disallowed; splitting the same payor-ATC pair across multiple rows in the same period is also rejected, because the module has no way to tell whether two identically-keyed rows are a legitimate second transaction or a data-entry duplicate. We could not confirm a specific RR, RMC, or RMO section that states the duplicate-TIN-ATC consolidation rule in those exact words — this is the module’s well-documented operating behavior rather than a quotable clause, so treat the general principle, not a specific citation, as the authority here. The current version of that module, Version 7.4, was announced in RMC No. 15-2025, and that circular confirms files that drew error replies from the eSubmission facility under an older version had to be corrected and resubmitted — consistent with the module actively rejecting non-conforming rows rather than silently accepting them.

Worked example: two BIR Form 2307 certificates, one payor, one ATC #

A bookkeeping contractor who invoiced the same corporate client twice in one quarter received two separate BIR Form 2307 certificates from that client, both withheld under the same ATC — and listing both certificates as separate SAWT rows is exactly what triggers the duplicate-TIN-ATC rejection. Names and TINs below are fictional for illustration only.

Dela Peña Bookkeeping Services billed Pacific Grain Traders Inc. twice during Q2 2026 — once for an April engagement and once for a June engagement — and Pacific Grain Traders withheld 10% under Alphanumeric Tax Code WI010 (professional fees paid to an individual payee with a sworn declaration on file) on both invoices:

The wrong way — two separate rows with the same key:

444555666000|PACIFIC GRAIN TRADERS INC|WI010|80000.00|8000.00
444555666000|PACIFIC GRAIN TRADERS INC|WI010|95000.00|9500.00

Both lines carry the identical payor TIN (444555666000) and the identical ATC (WI010). The validation module reads the second line as a duplicate of the first rather than as an additional transaction, and the file is rejected before it ever reaches a reviewer.

The corrected way — one consolidated row:

444555666000|PACIFIC GRAIN TRADERS INC|WI010|175000.00|17500.00

The single row carries the combined income payment (₱80,000.00 + ₱95,000.00 = ₱175,000.00) and the combined tax withheld (₱8,000.00 + ₱9,500.00 = ₱17,500.00). Both certificates are still fully accounted for — nothing is dropped — but the file now presents one line per payor-ATC pair, which is what the module expects.

Step-by-step: fixing a duplicate TIN-ATC rejection #

Fixing this rejection is a consolidation task, not a data-correction task — none of the individual rows is “wrong,” so the fix is to merge them rather than edit any single row’s figures. Work from the certificates, not from the rejected file, so the combined totals stay traceable.

1. Open the validation report from the Alphalist Data Entry and Validation Module and note every payor TIN-ATC pair it flags as duplicated.
2. Pull every BIR Form 2307 certificate for that payor and that ATC covering the SAWT period — not just the two you remember, since a third certificate from the same payor under the same ATC would also need to be folded in.
3. Add up the income payment and the tax withheld across those certificates by hand or in your working spreadsheet, keeping a visible subtotal so you can check it against the certificates later.
4. Delete the duplicate rows in the source spreadsheet and replace them with a single row carrying the payor TIN, payor name, ATC, and the two summed totals.
5. Regenerate the DAT file from the corrected spreadsheet.
6. Re-run the file through the Alphalist Data Entry and Validation Module and confirm the duplicate-TIN-ATC flag no longer appears.
7. Reconcile the consolidated row’s totals against the underlying certificates one more time before submitting — see SAWT Reconciliation with BIR Form 2307 for the full tie-out routine — then file the SAWT with the return it supports.

What if the two certificates carry different ATCs? #

If the second certificate from the same payor was withheld under a different ATC than the first, the duplicate-TIN-ATC rejection should not occur at all, because the two rows no longer share the same key. In that case each certificate keeps its own SAWT row — one for each ATC — since the ATC on the row must always match the ATC actually printed on the certificate behind it, not a code you standardize for convenience. The worked multi-certificate example in How to Build a SAWT DAT File From Multiple BIR Form 2307 Certificates covers that different-ATC, different-payor scenario in detail. The consolidation fix in this guide applies only when the TIN and the ATC are both identical across the rows.

Summary #

A SAWT DAT file rejected for a duplicate TIN-ATC combination has two rows sharing the same payor TIN and the same ATC for the period — most often because multiple BIR Form 2307 certificates from one payor under one ATC were transcribed as separate rows instead of being added together. The fix is to pull every certificate for that payor-ATC pair, sum the income payment and tax withheld across them, replace the duplicate rows with one combined row, and re-validate before filing. In the worked example above, two certificates totaling ₱175,000.00 in income payments and ₱17,500.00 in tax withheld became one SAWT row instead of two. For what SAWT is and why it’s required at all, see What Is SAWT?; for the full reconciliation routine before you file, see SAWT Reconciliation with BIR Form 2307; and for the rest of the common validation failures, see Common SAWT DAT File Errors and How to Fix Them.