How to Prepare SAWT and QAP From BIR Form 2307

Certificates you received from customers who withheld from your income feed the Summary Alphalist of Withholding Taxes (SAWT), which you attach to the return where you claim the creditable withholding tax credit. Certificates you issued to your own suppliers feed the Quarterly Alphalist of Payees (QAP), which accompanies BIR Form 1601-EQ and is due not later than the last day of the month following the close of the quarter.

Both files come out of the same fields on the same certificate: the payor's and payee's registered name and TIN, the ATC, the income payment segregated per month of the quarter, and the tax withheld. Both end up as a .DAT file produced through the BIR Alphalist Data Entry and Validation Module. What changes between them is whose TIN sits in each row and which return the file is keyed to.

If you keep the books for a company of any size, you almost certainly owe both for the same quarter, built from two separate stacks: the certificates that arrived from customers, and the copies of the ones you issued to suppliers. Sorting by direction before anything else is the entire setup, and it is where the confusion usually starts, because the two obligations are almost always explained on separate pages that never reference each other.

The name is a second small source of confusion, and both versions of it are the BIR's own. RR 2-2006 titles the file the Summary Alphalist of Withholding Agents. The BIR's Alphalist Data Entry Module labels the screen Summary Alphalist of Withholding Taxes. Neither is wrong, and they point at the same file. The regulation's wording is the more useful of the two, because it encodes the fork: a payee's SAWT is a list of the withholding agents who withheld from it.

Most published guidance on how to prepare SAWT from 2307 certificates begins at the point where the data has already been keyed in, and works through the Alphalist module's screens from there. That is the back half of the job, and it is covered thoroughly by the BIR's own materials, by free converters, and by every accredited package on the market. The front half, turning a physical or PDF stack of certificates into the rows the module expects, is where the hours actually go, and almost nothing addresses it. Everything below works forward from the certificate itself, up to the point where the module takes the data and produces the official .DAT.

Reading a BIR Form 2307: Every Field That Matters

The certificate is BIR Form No. 2307, Certificate of Creditable Tax Withheld at Source, January 2018 ENCS. That revision is still the current one, so a certificate arriving on an older layout is worth a second look.

Item 1 sets the period covered, From and To. This is what determines which quarter's alphalist the certificate belongs to, and it is the first field to read rather than the last, because a certificate covering a period that straddles your filing quarter needs resolving before anything else gets captured.

Part I, Payee Information, carries the payee's TIN, the payee's name (Last, First and Middle for an individual, or the Registered Name for a non-individual), the registered address with ZIP code, and a foreign address where one applies.

Part II, Payor Information, is the mirror image: the payor's TIN, name, registered address and ZIP code.

Part III is where the money is, and it is in two blocks rather than one. The first block, Details of Monthly Income Payments and Taxes Withheld, runs the columns Income Payments Subject to Expanded Withholding Tax, ATC, 1st Month of the Quarter, 2nd Month of the Quarter, 3rd Month of the Quarter, Total, and Tax Withheld for the Quarter.

The second block is the one most write-ups skip entirely: Money Payments Subject to Withholding of Business Tax, covering both government and private payors. A single certificate can carry entries in this block as well as in the expanded withholding block above it. Capturing only the first block is a quiet way to lose rows, and the loss will not show up until the totals fail to tie.

The TIN is longer than you think

Current forms render the TIN as a 9-digit base plus a branch code, where the last five digits of the 14-digit TIN are the branch. Older material and older habits normalize the branch to three digits, which produces a value the module will not match. Whatever you do with the TIN downstream, keep it whole and keep it as text, because the leading zeros in a branch code are the first casualty of a spreadsheet that decides the field is a number.

One certificate is not one row

A certificate can carry more than one ATC line. A supplier billing you for both professional services and rental in the same quarter produces one certificate with two coded lines and two separate tax computations. That makes the ATC line the unit of extraction. This determines the shape of every table you build from here, so it is worth settling before you capture anything.

The ATC prefixes go past WI and WC

Most guidance stops at two prefixes: WI for an individual payee, WC for a corporation. The pairs run in parallel, so professional fees are WI010 and WI011 against WC010 and WC011, rentals are WI100 and WC100, and top withholding agent purchases are WI158 and WC158 for goods, WI160 and WC160 for services.

Two more prefixes appear on the certificate's own ATC schedules and belong in your capture list:

• WB, money payments subject to withholding of business or percentage tax, where the payor is a government entity.
• WV, VAT withholding, with WV012 on goods and WV022 on services.

New ATC pairs continue to be added through eBIRForms package releases. Validate the code on an incoming certificate against the current ATC table in the module rather than against the list you memorized two years ago, particularly for codes you have not seen before.

The CONFORME line at the foot of the certificate is the payee's acknowledgement of receipt. It matters for your file copy and for any dispute about whether a certificate was actually furnished, but it carries nothing into the alphalist.

How the certificates reach you

Almost none of this arrives as paper anymore. Certificates come as email attachments, scans, and phone photographs of scans, and the BIR moved in the same direction on submission: hard copies of Form 2307 were replaced by scanned soft copies under RR 16-2021 and RMC 117-2021, submitted through eAFS or on DVD. That shift sits inside a wider program that also covers the BIR Electronic Invoicing System rollout, and its practical consequence for this job is that the source documents you are extracting from are already digital, in whatever mix of quality the counterparty's scanner produced.

The Alphalist Columns Your Spreadsheet Has to Produce

The module's data entry screen captures nine values per row, and the list is essentially the same whether you are building a SAWT or a QAP:

Alphalist column	Where it comes from on the 2307
For the month of	Item 1 period, split into the individual month the amount falls in
Sequence Number	Assigned by you, not on the certificate
TIN (with branch code)	Part II payor TIN for a SAWT; Part I payee TIN for a QAP
Registered Name	Part II payor name for a SAWT; Part I payee name for a QAP
Last / First / Middle Name	Same source, where the counterparty is an individual
Alphanumeric Tax Code	Part III, ATC column, per line
Amount of Income Payment	Part III, the 1st, 2nd or 3rd month column for that month
Tax Rate	Implied by the ATC and the amounts
Amount of Tax Withheld	Part III, apportioned to the month

An alphalist row is monthly, not quarterly

This is the transformation that catches out anyone building the spreadsheet from the certificate's own layout. The 2307 presents the quarter horizontally: one line per ATC, with three month columns running across it. The alphalist wants the same data vertically, one row per month, with the module aggregating to the quarter total. A certificate with two ATC lines and amounts in all three months is six alphalist rows, not one and not two.

The requirement comes straight from RR 11-2018, which specifies that the QAP reflect the amount of income paid segregated per month with a total for the quarter. If your extracted table has a single row per certificate with three amount columns, you have the certificate's shape, not the alphalist's, and the difference is a manual unpivot across every row you captured.

Registered address is not a row field

The registered address is on the certificate and it is not an alphalist column. The module captures address once, in the Withholding Agent Information screen and the TIN Library, not per payee row. Building a spreadsheet with an address column per row does no harm on its own, but treating address as a required capture field adds work and, worse, sets an expectation that the row will map one-to-one into the module when it will not.

Where SAWT and QAP genuinely differ

Three things, none of them the column list:

Whose TIN is in the row. A SAWT row identifies a withholding agent who withheld from you. A QAP row identifies a payee you withheld from. Same schema, opposite direction, and this is the point at which mixing the two stacks produces a file that validates cleanly and is completely wrong.

Which return the file is keyed to. A QAP is keyed to BIR Form 1601-EQ, and the same module path also covers 1601-FQ for final withholding taxes. A SAWT is keyed to whichever return carries the credit you are claiming.

QAP carries a second schedule. The alphalist of other payees whose income payments are exempt from withholding tax but subject to income tax, reported under Form 2304, sits alongside the main schedule and has no tax rate and no tax withheld columns. It exists because the QAP is not a list of who you withheld from; it is a list of the income payments prescribed as subject to withholding, whether or not tax was actually withheld. Payees dropped from the file on the grounds that nothing was withheld from them are a real compliance exposure, and it is one of the more common omissions.

Which returns a SAWT actually attaches to

The live attachment points are 1701Q, 1701, 1702Q, 1702, 2550Q and 2551Q. RR 2-2006's original list, and the module's own form picker, still show 2550M. Monthly VAT filing on 2550M was discontinued from 1 January 2023 and VAT is quarterly only, so the picker is carrying a form that no longer exists. Any guidance that routes a SAWT to 2550M was written before that change and has not been revisited.

The SAWT itself has no deadline of its own. It is due with the return it supports, which means the quarterly income tax return, the quarterly VAT return, or the annual return, depending on where the credit is being claimed. Guidance that assigns the SAWT a fixed annual date is describing something else.

Worth noting where the return is 2550Q, because the SAWT is rarely the only attachment that quarter: the Summary List of Sales and Purchases goes with it, and building the SLSP out of a quarter of sales and supplier invoices is a separate extraction from a separate stack of documents on the same due date.

---

Turning a Quarter of Certificates Into Alphalist Rows

The target is now concrete: a spreadsheet whose columns match the schema above, one row per ATC line per month, covering every certificate in the quarter's stack. That is a different document from the one most bookkeepers actually produce, which is a running list of certificates with a total at the bottom.

Whatever method you use to get there, the instruction has to carry three things or the output will need reworking:

• Name the columns explicitly. Registered name, TIN with branch, ATC, month, income payment, tax withheld. A generic request to pull the data off the certificate returns the certificate's fields rather than the alphalist's.
• State the row unit. One row per ATC line per month. Without this you get one row per certificate, and the unpivot is manual.
• Handle the month split. The three month columns on the certificate have to become three rows carrying the same counterparty and ATC.

Four capture rules go with those, and each exists because breaking it costs a rework: registered name exactly as printed rather than the trading name on the letterhead or the shorthand in your ledger, TIN as text with the branch code intact, ATC verbatim (the prefix carries the individual-versus-corporate distinction, so WI100 read for WC100 is a substantive error), and amounts natively typed as numbers so the reconciliations below run as pivots instead of a cleanup exercise.

Where the extraction step ends

This is worth stating plainly, because it is the boundary that most tool pages blur. What comes out of this step is an alphalist-shaped spreadsheet. It is not a filed return and it is not a .DAT file. You take that data into the BIR Alphalist Data Entry and Validation Module, or into accredited software, and that is what validates it and emits the official .DAT for submission.

The reason the front half is worth solving separately is the shape of the workload. This is not a steady trickle. Certificates arrive in a burst after each quarter closes, and a practice carrying fifteen clients is carrying fifteen stacks in the same fortnight, each one a different set of counterparties and codes. A per-certificate workflow scales linearly with the client list, which is why the deadline pressure is always at the keying stage and never at the module.

Invoice Data Extraction, our own tool, exists for the front half of exactly this kind of job. You upload the quarter's certificates and describe the output you need in plain language, with no template to configure first, and it returns an Excel, CSV or JSON file built to that description. For this job the description is the alphalist schema itself, along the lines of: Extract one row per ATC line per month from each BIR Form 2307. Columns: Month, Payee TIN with branch code (text), Registered Name, ATC, Income Payment, Tax Withheld. The certificate shows three month columns on one line, so create a separate row for each month that carries an amount. Capture the registered name exactly as printed. Prompts like that can be saved to a prompt library and reapplied next quarter, and per client, which is what makes the output consistent across filings rather than dependent on who did the keying.

The practical fit is in the volume and the checking. Batches run to 6,000 files, and a single PDF can run to 5,000 pages, so a merged scan of a whole quarter's certificates is one job rather than a splitting exercise first. Every output row carries a reference back to its source file and page, so when a total does not tie you can go straight to the certificate that produced the row instead of re-reading the stack. Where a value is genuinely unclear, a faint scan, a handwritten amendment, an ambiguous code, it is flagged as Review Needed with a note on what to check, rather than filled in with a confident guess. On a file where a wrong TIN or a wrong ATC means a rejected alphalist, being told which rows to look at is the useful behavior.

If you want the mechanics of the general case rather than this specific form, converting a batch of PDF documents into Excel rows covers the same workflow applied to invoices. For this one, you can extract the data from a whole quarter of 2307 certificates in one batch and take the resulting table straight into the reconciliations below, then into the module.

Two Reconciliations to Run Before You File

Both of these are pivots once the table is in alphalist shape, and both are far cheaper now than after an assessment notice arrives.

Payee side: certificates received against the credit claimed

Total the tax withheld across every 2307 you received for the quarter, and tie it to the CWT credit on the return the SAWT supports. The two directions of a variance mean different things and carry different costs.

Credit claimed exceeds certificates on hand. A certificate is missing, or has not arrived yet, and the excess is precisely the amount exposed to disallowance. This is the expensive direction, because the credit is already on a filed return and the support is not in the file.

Certificates on hand exceed credit claimed. A certificate arrived and was never picked up in the books. Nobody will ever chase you about this one, which is exactly why it persists, and it is money the client has already paid to the BIR and is not claiming.

Withholding agent side: certificates issued against remittances

Total the tax withheld across the certificates you issued, and tie it to what was remitted on 1601-EQ for the quarter and to the QAP totals. A gap is either an under-remittance or a certificate issued for tax that was never remitted. The second is worse: you have given a counterparty documentary support for a credit against money the BIR never received, and the certificate is the evidence.

Running them

Pivot the extracted table by month and by ATC, on tax withheld, and compare against the return. Grouping by ATC does a second job beyond the totals, because it surfaces the case where the correct amount was withheld under the wrong code. The quarter total ties, the return looks fine, and the alphalist reports the payment against a code whose expected rate does not match the amount.

Run the comparison at month level rather than quarter level. Both the remittance and the return are monthly-sensitive, and a quarter-level total will happily net two offsetting monthly errors into a clean tie.

The third check: who is missing entirely

The reconciliations above only compare what you have. The certificates that never arrived are invisible to both.

Take the payee list from the extracted table and run it against the client's revenue ledger for the quarter, on the payee side, or the supplier ledger on the agent side. Counterparties that appear in the ledger with payments subject to withholding, and do not appear in your certificate stack, are the gaps. That comparison is the only reliable way to find a missing 2307 before the return is filed rather than a year later when the credit is questioned.

Do all of this before encoding into the module. Correcting a spreadsheet is a filter and a retype. Correcting an alphalist that has been validated and submitted is a different conversation with your RDO.

Encoding, Validating, and Submitting the DAT File

The clean table goes into the BIR Alphalist Data Entry and Validation Module, which validates the entries and emits the .DAT file. Accredited software does the same job through its own interface. Either way, this is the step that produces the artifact the BIR accepts, and nothing upstream of it substitutes for it.

Version 7.4 is the current module release at the time of writing, issued under RMC 15-2025 and posted in February 2025 in place of version 7.3. Check the BIR's downloadables page before a filing rather than trusting the copy installed on the workstation, because these releases are how new ATCs and updated withholding rates reach the module. Guidance still telling you to run 7.0 or 7.2 predates two releases of code table changes.

Which route the file takes

Three channels, and they are not interchangeable:

• eFPS, as an electronic attachment, for filers enrolled in the system.
• eSubmission, with the .DAT emailed to [email protected] or to the revenue district officer's email account.
• eAFS, for the scanned attachments to an income tax return. This means the 2307 certificates themselves and the eSubmission confirmation.

That last one is where most published guidance goes wrong. eAFS is not the route for the .DAT alphalist file. The alphalist goes through eFPS or eSubmission; eAFS receives the scanned supporting documents, including proof that the alphalist was submitted. Sending the .DAT through eAFS and stopping there leaves the alphalist unfiled.

The subject line, and what actually counts as filed

The BIR and individual RDOs prescribe a subject-line format for eSubmission emails, and the formats circulating online conflict with each other. Use the format your RDO specifies rather than one copied from a blog post.

Submission is complete when the BIR returns the validation report or the successful-validation acknowledgement. That acknowledgement is what you retain in the file, and for an income tax return it is what gets uploaded through eAFS alongside the scanned certificates. An email sent without a returned acknowledgement is not a filed alphalist, and the gap usually surfaces at the worst possible moment.

Deadlines

• QAP: with 1601-EQ, not later than the last day of the month following the close of the quarter.
• SAWT: no separate deadline. Due with the return it supports.
• Annual 1604-E, with its Annual Alphabetical List of Payees: on or before March 1 of the following year, per RR 11-2018 and the form's own guidelines.

On the QAP, Grant Thornton Philippines' tax note on submitting the QAP states the rule in full: it must be attached to the quarterly remittance return of creditable income taxes withheld, BIR Form No. 1601-EQ, and submitted on or before the last day of the month following the close of the quarter, through the BIR e-submission facility at [email protected] or the email account of the revenue district officer. The same deadline and the same route cover the QAP accompanying 1601-FQ for final withholding taxes, so a firm withholding on both counts is submitting two files rather than one.

The four quarterly QAPs should reconcile to that annual alphalist. If they do not, the difference is a quarter that was filed with an error nobody caught, and March is a poor time to find it.

The alphalist is an attachment to, and therefore part of, the withholding tax return. RMC 55-2026, issued in May 2026, restates this directly. The practical consequence is that failing to submit it is a penalizable violation rather than an administrative loose end, and the return is not complete without it.

For firms running a registered accounting system, none of this changes. A CAS changes what produces the underlying transaction data and what the BIR has approved you to generate, and the BIR Computerized Accounting System registration requirements govern that side of it, but the alphalist obligation, the module, and the submission routes are the same.

Why Alphalists Fail Validation, and How to Handle Late Certificates

The module's rejection messages are terse, and at eleven at night on a deadline they are not much help. Almost every rejection traces back to one of a short list of causes, and all of them are cheaper to prevent at capture than to diagnose at validation.

Registered name mismatches. The alphalist matches against the name registered with the BIR, not the trading name on the letterhead and not the shorthand in the client's ledger. Inc. against Incorporated, a dropped comma, an ampersand against "and", a missing corporate suffix. Resolve each counterparty's registered name once and keep the mapping. Rebuilding it from scratch every quarter guarantees that the same three suppliers fail every time.

TIN and branch code errors. A TIN entered without its branch, with the wrong branch, or with leading zeros stripped by a spreadsheet that read the field as a number. The last one is entirely preventable by capturing the TIN as text and never letting it be anything else.

ATC inconsistency. The same counterparty coded one way this quarter and another way last quarter, or an individual payee carrying a corporate ATC. Because the code implies the expected rate, a mismatch between the ATC and the amount withheld is both a common rejection and a genuine substantive error. If the module objects to the rate, the ATC is usually what is wrong, not the amount.

Multi-code certificates captured as one row. A certificate with two ATC lines collapsed into a single row understates the row count and misstates the per-code totals, and the quarter total can still tie perfectly while it does so.

Payees omitted because nothing was withheld. On the QAP side, income payments prescribed as subject to withholding belong in the file whether or not tax was actually withheld, including those covered by an exemption. Dropping them produces a file that validates and is incomplete.

Partial-quarter certificates. A relationship that started or ended mid-quarter produces a certificate with amounts in only one or two months. That is correct as issued. Do not force it into three monthly rows, and do not treat the blank months as missing data.

Which quarter does the payment belong to

The EOPT Act, RA 11976, changed the timing of the withholding obligation to the point at which the income becomes payable, replacing the earlier rule that keyed off the earlier of accrual or payment. For payments sitting near a quarter boundary, that determines which quarter's certificate and which quarter's alphalist they belong in, and a firm that has not adjusted its cut-off practice will produce certificates that disagree with its own books.

EOPT also removed withholding as a condition for deducting the expense, which changes the consequence of a missed withholding but not the reporting obligation. The alphalist still has to reflect it. The broader set of changes, including what they did to documentation on the sales side, is covered in Philippine invoice requirements after the EOPT Act.

Certificates that arrive late, or not at all

On the payee side this is perennial, and the handling is mostly about sequence.

Find the gap during the reconciliation, not at filing. The ledger comparison in the previous section is what turns "we are probably missing a couple" into a named list of counterparties.

Chase against the regulation rather than against goodwill. RR 11-2018 requires the payor to furnish the certificate within twenty days from the close of the quarter, and where the payee requests it, to furnish it simultaneously with the income payment. That second provision is the useful one and is widely forgotten: a client who asks for the 2307 at the point of collection is entitled to it then, which removes the chase from the quarter-end crush entirely. It is worth building into the collection process for any customer who withholds routinely.

Where a certificate turns up after the return has already been filed, the principle is straightforward even though the mechanics are not: the credit needs its supporting certificate, so it has to be brought in through the appropriate amendment or subsequent return rather than claimed and left unsupported. The specific route depends on which return carried the credit and how long ago it was filed. Take that one to your RDO or your tax adviser rather than to a template.

Nearly everything on this list originates at the keying stage, not at the module. The module is only reporting what it was given. That is the argument for spending the effort on how the data comes off the certificates in the first place, rather than getting progressively faster at interpreting rejection messages.