What is the branch code on a TIN, and why does SAWT care about it?

A Philippine TIN is a 9-digit base number plus a separate branch code — 000 for the head office, 001 and up for registered branches. SAWT DAT files report payee identity by TIN and branch code together, because the BIR tracks withholding credits at the branch level, not just the TIN level, so the pairing has to match what that payee's BIR Form 2307 certificate and BIR registration actually show.

Can I just use 000 for every payee's branch code to keep things simple?

No. Using 000 for a payee that is actually registered and invoicing as a branch (001 or higher) either fails the Alphalist Data Entry and Validation Module's format check or, if it passes structurally, creates a payee record that doesn't match the TIN-and-branch combination on the certificate it's meant to summarize.

Where do I find the correct branch code for a payee?

The payee's own BIR Form 2307 certificate, Certificate of Registration (BIR Form 2303), or official receipt header is the most reliable source — these documents show the exact TIN-and-branch-code combination that payee is registered under at the RDO that issued it.

Does a branch-code mismatch always cause a hard validation error?

Not always. A structurally valid but factually wrong branch code (right length, wrong digits) can pass the Alphalist module's format check and still create a silent mismatch against the underlying BIR Form 2307 certificate, which surfaces later during reconciliation or audit rather than at upload.

What's the fix once a branch-code mismatch is found?

Correct the branch-code field in the source spreadsheet to match the payee's certificate or registration record, keep it in its own column separate from the 9-digit base TIN, and regenerate the DAT file before resubmitting — never merge the branch code into the TIN field itself.

Why Your SAWT DAT File Gets Rejected When the Payee's Branch Code Doesn't Match Its RDO Registration

A SAWT DAT file row that pairs a payee’s correct 9-digit TIN with the wrong branch-code suffix — reporting a branch’s withholding under the head office’s 000 code, or the reverse — either fails the BIR Alphalist Data Entry and Validation Module’s format check outright, or passes structurally and then silently breaks the reconciliation against that payee’s own BIR Form 2307 certificate. The branch code is a separate, required field under the same alphalist structure RR No. 2-2006 attaches to a creditable withholding tax (CWT) claim, not an optional suffix.

This guide is part of this site’s SAWT coverage. For building the file itself, see How to Convert Excel to BIR DAT File for SAWT; for tying SAWT totals to certificates on hand, see SAWT Reconciliation with BIR Form 2307; for the other structural errors that block a SAWT upload, see Common SAWT DAT File Errors.

Build Your SAWT Without Branch-Code Errors — FREE →

What is the branch code, and why does it matter on a SAWT row? #

Every Philippine TIN is a 9-digit base number, and every registered taxpayer — individual or corporate — also carries a separate branch code that identifies which specific registration (head office or a numbered branch) a given transaction belongs to. The head office is conventionally 000; a registered branch carries 001 or a higher sequential number assigned at BIR registration.

A SAWT row needs both pieces, kept as distinct fields, because:

The TIN alone doesn’t identify which registration issued the certificate. A corporation with several branches can have withholding activity booked under more than one branch code, each potentially tied to a different RDO.
BIR Form 2307 certificates carry the issuing payee’s own TIN-and-branch combination, and SAWT exists to summarize those certificates — not a generic TIN lookup.
The Alphalist Data Entry and Validation Module checks branch-code format as part of the same identity-field validation applied to the base TIN, as covered for the base-TIN side of this check in Common SAWT DAT File Errors.

How does a branch-code mismatch actually surface? #

A mismatch shows up one of two ways: as an outright structural rejection if the branch-code field is malformed, or — more dangerously — as a silent pass that only breaks later when the SAWT total is checked against the certificate it’s meant to represent. Both failure modes trace back to the same root cause: the branch code wasn’t pulled from the payee’s actual registration.

Structural rejection. A branch code merged into the 9-digit TIN field, left blank, or padded to the wrong number of digits fails the Alphalist module’s format check the same way a malformed base TIN does.
Silent reconciliation break. A branch code that is the right length and looks plausible — say, 000 typed by default — but doesn’t match what the payee’s certificate actually shows (001, because the payment was invoiced from a branch, not the head office) passes structural validation. The row then doesn’t tie out to the certificate behind it when reconciled, the exact failure mode described in SAWT Reconciliation with BIR Form 2307.

“Most SAWT DAT failures come from data that does not meet the Alphalist Data Entry and Validation Module’s format rules — invalid or wrong-length TINs, inconsistent branch codes, malformed return periods — or from detail rows whose income payment and tax withheld do not match the BIR Form 2307 certificates the SAWT is supposed to summarize under Revenue Regulations No. 2-2006.”
— summarizing the Alphalist validation standard applied under RR No. 2-2006, as stated in this site’s own SAWT error guide

Worked example: a supplier that invoices from a branch, not head office #

The scenario below is fictional, built only to show how a wrong default branch code creates a mismatch even when the base TIN is correct. Solana Facilities Services Corp. (fictional TIN 234-567-890) is headquartered in Quezon City but operates a separate registered branch in Cebu (branch code 001) that handles all of its Visayas-area maintenance contracts.

Landmark Properties Inc. pays Solana ₱90,000 for a maintenance contract serviced and invoiced entirely out of the Cebu branch. Solana issues a BIR Form 2307 showing TIN 234-567-890, branch 001, for that payment.

Field	What the certificate shows	What was typed into the SAWT spreadsheet	Result
TIN	234-567-890	234-567-890	Matches
Branch code	001 (Cebu branch)	000 (default head office)	Mismatch
Income payment	₱90,000.00	₱90,000.00	Matches

The TIN and amount are both correct, but the branch code defaulted to 000 instead of the 001 shown on Solana’s actual certificate. The row may still pass the Alphalist module’s structural check — 000 is a valid-looking branch code — but it no longer matches the certificate it’s supposed to summarize, which is exactly the gap a reconciliation pass is meant to catch before the return is filed.

How to find and fix the correct branch code #

The payee’s own documents, not an assumption, are the source of truth for its branch code. Before finalizing a SAWT DAT file:

Pull the branch code directly from the payee’s BIR Form 2307 certificate for that period — it’s printed alongside the TIN on the certificate itself.
Cross-check against the payee’s BIR Form 2303 (Certificate of Registration) or an official receipt header if the certificate is unavailable or unclear.
Keep the branch code in its own spreadsheet column, formatted as text, never merged into or appended onto the 9-digit base TIN.
Never default to 000 for a payee simply because it’s the common case — confirm it for each payee, especially one known to operate multiple registered branches.
Re-run the file through the Alphalist Data Entry and Validation Module after correcting the field, and separately re-check the row against the certificate total, since a corrected branch code that still doesn’t match the certificate’s income or tax-withheld figures is a different error.

Summary #

A SAWT row’s branch code is a required, separate field alongside the 9-digit TIN, and it has to match what the payee’s own BIR Form 2307 certificate and BIR registration actually show — not a default or an assumption — because RR No. 2-2006 ties the SAWT alphalist to the certificates it summarizes at that level of detail. A wrong branch code either fails the Alphalist Data Entry and Validation Module outright or, worse, passes format validation and quietly breaks the reconciliation against the certificate behind it. Pull the branch code from the certificate or registration record every time, keep it in its own field, and re-validate after any correction. For the other structural SAWT errors to clear at the same time, see Common SAWT DAT File Errors; for the reconciliation step this feeds into, see SAWT Reconciliation with BIR Form 2307.