Three Matches a 2307 Needs
to Become a SAWT or QAP Row

Two Alphalists, One Certificate Layout

An alphalist is the line-by-line list a taxpayer attaches to a return. The SAWT is the payee's list of the withholding agents that deducted tax from its income, and the QAP is the withholding agent's list of the payees it deducted from. They are the same transactions seen from opposite sides. The BIR's alphalist module calls the first file the Summary Alphalist of Withholding Taxes; Revenue Regulations (RR) 2-2006 describes it as a summary of withholding agents. Both names point to the same attachment.

The SAWT has no filing date of its own. It is attached to the return where you claim the creditable withholding tax (CWT) credit, which can be the 1701Q or 1702Q income tax return, or the 2550Q VAT return, depending on the taxpayer and the credit. The QAP is attached to the 1601-EQ, the quarterly expanded withholding tax return, or the 1601-FQ for final withholding tax, and it is due on the last day of the month following the close of the quarter. The QAP shares the 1601-EQ's deadline, which means it cannot be filed after the return without being late.

The row unit is smaller than the certificate. An alphalist line is one counterparty, one ATC and one month. A certificate with two ATC lines and amounts in all three months can produce six alphalist lines. That is the first shape change, and it explains why a table built by copying the certificate one row per page looks finished while the file is still wrong.

The module does not read the certificate. It accepts keyed entries or a .DAT file. The .DAT is the plain-text data file the module produces. The module then checks the structure against its own tables and returns a report. Everything before that point is a data-preparation job: turning a stack of certificates into rows with the right period, identity and amount.

The Fields Are on the Certificate, in the Wrong Shape

Every value the alphalist asks for is already printed on the 2307. The work is knowing which box supplies which column. The January 2018 version of the form lays the certificate out in three parts, plus the signature page.

The Taxpayer Identification Number (TIN) on a 2307 runs to 14 digits: a nine-digit base plus a five-digit branch code. Keep it as text from the moment it leaves the certificate. A spreadsheet that reads the field as a number drops the leading zeros in a branch code, and the row then fails a match it would otherwise pass. A head office and a branch are different withholding agents, and their TINs differ only in those last five digits.

The ATC is the Alphanumeric Tax Code, and its first two letters tell you which side of the withholding system you are on. WI is an individual under expanded withholding, WC is a corporation, WB is business tax withholding and WV is VAT withholding. The code also carries the expected rate. Professional fees paid to an individual are WI010 at 5% or WI011 at 10%; the same fees paid to a corporation are WC010 at 10% or WC011 at 15%. Which one applies depends on the payee's gross income and, for individuals, VAT status, and the ATC schedule printed on the certificate is the authority for the code.

A certificate can carry more than one ATC line, and it can carry both the expanded withholding block and the business tax block. Capture only the first block and the business tax withholding never reaches the table you reconcile. The quarter total can still look plausible because the missing line is also missing from the total you copied.

The certificate is horizontal: one ATC line with three month columns running across it. The alphalist is vertical: one line per ATC per month. That reshape is the first place rows get lost.

Match One: The Period Decides the Quarter

Read Item 1 before the amount, because a correct amount in the wrong quarter is still a rejected credit. The certificate states the income period, and that period decides the quarter. The date the certificate was signed or emailed does not. A certificate issued on 5 July for June income belongs to the second quarter, not the third.

Three period failures are common. The first is a certificate whose Item 1 falls outside the quarter you are filing: a payor sends a certificate for January to March while you are preparing the third quarter, and it gets keyed into the open quarter because that is the folder it landed in. The second is a certificate that covers a period wider than a quarter, which usually means the payor consolidated several quarters into one form. The third is a certificate whose month columns contradict its own period, with Item 1 saying April to June while the first-month column carries a March payment. In each case, the fix is a corrected certificate or a deliberate decision about the correct quarter. Editing the row to fit the open quarter hides the problem until the cross-match.

Read the three month columns as a set. The amounts in the first, second and third month of the quarter have to sit inside the period in Item 1, and the total has to equal their sum. A blank month is normal for a relationship that started or ended mid-quarter. A month that falls outside the period is not normal.

The deadlines put the quarter under pressure. The QAP is due with the 1601-EQ or 1601-FQ on the last day of the month after the quarter. The SAWT is due with whichever return carries the credit. The 1701Q runs on 15 May, 15 August and 15 November; the 1702Q on the 60th day after the quarter; the 2550Q on the 25th day. Dates move when they fall on weekends or holidays, so check the current BIR calendar rather than a table copied from an old post.

Quarterly cut-offs are not unique to the Philippines. The UK P11D filing compresses a year of benefits into a July deadline, Japan's year-end withholding statements arrive in a January batch, and Spain's Modelo 303 is built from a quarter of invoices. The Philippine version is unusual because the same certificate layout feeds two alphalists in opposite directions.

A certificate issued after the quarter closes is normal. A certificate whose Item 1 falls outside the quarter you are filing is not.

Match Two: The TIN and Registered Name Decide the Row

The alphalist matches a counterparty by identity, so a correct amount under the wrong TIN is a missing row, not a small error. Identity is decided per certificate, not per vendor card. A customer that pays from its head office for one contract and from a branch for another can issue two 2307s with two TINs. The SAWT is a list of withholding agents, so those are two rows. Merge them into one and the branch code on one certificate has nowhere to go; the single row matches neither of the payor's entries.

The same split appears on the QAP side. A supplier may bill through a branch for part of the year and through the head office for the rest. Your accounting system has one vendor card, one contact and one payment history. The certificates carry two TINs. If you key the vendor card's TIN for both, one of the two rows is wrong, even though the name and amount look right.

Names fail in quieter ways. The registered name should be the name on the certificate, not the name on the letterhead and not the shorthand in your ledger. Suffixes matter when the two alphalists are compared. A missing "Inc." or a comma where the certificate has none can leave the row looking like a different counterparty. The validation rules also refuse names with special characters such as ñ, ?, and &, so an ampersand has to become the word "and" before the file will upload. They also refuse dummy TINs and lumped entries such as "Various payees". Those rules are about the file structure, not about the truth of the payment, but they decide whether the file is treated as received at all.

Build a counterparty master that holds the 14-digit TIN, the registered name exactly as printed, and the ATCs you have seen on that counterparty's certificates. Resolve each new counterparty once, at the first certificate, then reuse it. Rebuilding the mapping from the ledger every quarter guarantees that the same suppliers fail every quarter.

The same payor-payee identity discipline shows up in US 1099 work, where two systems have to agree on a TIN before a form is valid. A W-2 and 1099 field-mapping guide for CPA firms covers the equivalent check on that side.

A row with the right amount and the wrong branch code is not a near miss. It is a row the other side cannot match.

Match Three: The ATC and Amounts Against the Ledger

A quarter total that ties can still hide a month in the wrong column or an ATC that carries the wrong rate. The ATC is the rate, which is why the code and the amount have to be checked together. A payment keyed under WI010 instead of WC010 is a different row with a different expected rate, even when the income payment is identical.

Multi-ATC certificates are where rows disappear. A supplier that provides professional services and also rents space to you gets one certificate with a WI010 line and a WI100 line. If the certificate is keyed as one row, the two tax amounts can still add up to the same quarter total, so the reconciliation passes. The alphalist is missing a code, and the rate on the surviving line no longer explains the tax.

A rate change inside the quarter produces a different kind of mismatch. When a payee crosses the gross-income bracket that separates WI010 from WI011, the payor may withhold at 5% for January and February and at 10% in March. The certificate may show WI010 for the early months and WI011 for the later ones, or a single code with two effective rates if the payor did not switch codes. Check the tax against the income for each month. An average for the quarter will look close enough and still be wrong.

Divide tax withheld by the income payment for each ATC line and each month. That effective rate should match the rate attached to the ATC. A 7.5% result on a line coded WI010 is a signal: check the month split, the income amount and the code. The check is mechanical once the table exists, and it catches the error that quarter-level totals hide.

Tie the table to the ledger in two directions. On the payee side, compare the income payment for each customer and quarter to the revenue recorded in the sales ledger, and the tax withheld to the CWT receivable. On the withholding-agent side, compare the certificates issued to the payments in the purchase ledger and to the withholding actually remitted. Timing differences from credit notes, advances, or a payment made just after the quarter closes are real; investigate them rather than forcing a tie.

The two directions of a variance mean different things. If the credit you are claiming is larger than the certificates on hand, a certificate is missing or has not arrived, and the excess is the part exposed to disallowance. If the certificates on hand are larger than the credit claimed, the tax was withheld and never picked up. The second is quieter, and it is money already paid to the BIR that the client is not claiming.

Run the rate check per month and per ATC. A quarter-level total will happily net two offsetting errors into a clean tie.

The Fourth Match Happens Outside Your File

Your internal reconciliation can pass while the BIR's cross-match fails, because the other side filed a different TIN or amount. Revenue Memorandum Circular (RMC) 14-2025 describes the check in a claim for refund or credit of excess CWT: the processing office compares the CWT claimed in the taxpayer's SAWT with the annual or quarterly alphalist attached to the withholding agent's 1604-E or 1601-E. If the two sides agree, the 2307 is treated as verified. If they do not, the certificate on its own does not settle the question.

This is the part that surprises payees. A 2307 can be genuine, correctly printed and correctly keyed, and the SAWT row can still fail because the payor reported a different TIN, a different ATC or a different amount in its own QAP. The certificate is one half of the evidence; the payor's alphalist is the other half. PwC's summary of RMC 55-2026 describes the same data matching in the BIR's assessment process, so the exposure is not limited to refund cases.

You cannot repair that by editing your SAWT. If your row matches the certificate, the correction belongs on the payor's side: a corrected QAP or a corrected 2307. Before filing, for large or recurring payors, ask them to confirm that the TIN, ATC and amounts on the certificate match what they will report. Keep the confirmation with the certificate. It is a short email that saves a long assessment conversation.

Your SAWT can be right and still fail, because half the evidence sits in the payor's file.

The Certificates That Never Arrived Are Invisible

Every reconciliation above compares what you have. The certificate that never reached the folder appears in none of them. That is why the counterparty list has to be compared to the ledger, not just the certificates to each other.

On the payee side, take the customers with payments subject to withholding in the quarter and check which of them produced a 2307. On the agent side, take the suppliers you paid and check which of them received a certificate. A counterparty in the ledger with no certificate is either a payment that was not subject to withholding or a gap. The distinction matters, and only a person who knows the transaction can make it.

RR 11-2018 gives the payee a lever. The withholding agent must furnish the 2307 within 20 days after the close of the quarter, and on the payee's request it must be furnished at the same time as the income payment. The second half is the useful one: a supplier who asks for the certificate when collecting is entitled to it then, which takes the chase out of the quarter-end crush. Put that request into the collection process for any customer that withholds regularly.

Duplicates are the other silent error. When a payor cancels and reissues a 2307, the old copy often stays in the folder. RR 11-2018 says the same 2307 cannot be used twice for the same amount, payor and period, so the old certificate has to come out when the corrected one goes in. The same rule applies to a certificate that was scanned twice under two file names. Deduplicate on counterparty TIN, period, ATC, income amount and tax withheld, not on the file name.

A missing 2307 does not show up as a variance. It shows up as a credit you cannot support, or one you never claimed.

Pull the Quarter Into One Table Before Matching

The matching work belongs in a spreadsheet. The retyping is what makes the quarter compress. A practice handling many clients receives the stacks in the same fortnight, each with a different set of counterparties and codes, and the keying stage is where the deadline pressure sits.

This is the transcription step where ImageToTable.ai fits. Custom Column Extraction means you type the column names you want, and the AI locates each value by what it means on the page rather than by a fixed position. There is no template to build for each payor's layout. A scanned certificate, an eBIRForms PDF and a phone photo can go into the same batch and land in the same columns.

Computed columns do the arithmetic while the table is built. A column named Month Split Check (Total Income - 1st Month - 2nd Month - 3rd Month) returns the difference, so a certificate whose months do not add up stands out without a separate pass. Effective Rate (Tax Withheld / Total Income) gives you the rate to compare against the ATC. Both are row-level calculations on values already extracted, not separate formulas you have to maintain in Excel.

Batch processing is the other half. Upload the quarter's certificates in one batch and they merge into one table, one row per certificate. Review Mode with bbox verification lets you click a cell and see the region on the original scan that produced it, which is useful for overprinted, faint or handwritten certificates; you can turn on auto-annotation so the boxes are waiting when you review. For dense handwriting or complex layouts, a higher Model Tier uses a stronger underlying model on that batch.

The boundary is just as important. The output is one row per certificate, not the alphalist's one-row-per-ATC-per-month shape. A certificate with two ATC lines still has to become two sets of rows before it enters the module; the default output will not multiply the row for you. The tool produces an Excel, CSV or JSON table; it does not generate the .DAT file, submit through eBIRForms, eFPS or eSubmission, validate against BIR records, or match your table to the ledger or the payor's QAP. It removes the transcription and leaves the reconciliation with you.

Use extraction for the part that is transcription, not the part that is judgment.

The Pre-Filing Pass, in the Order Failures Surface

Most module errors were created at capture. The validation report only names them. Run the checks in the order the failures actually surface, because a period error makes every later total meaningless.

Once the table is clean, the sequence is short: encode the rows in the module, run the validation, fix the rows the report names, generate the .DAT, submit through eFPS, eSubmission or the RDO email, and keep the acknowledgement. The table is the input; the module is the format check.

The module release matters because new ATCs and updated rates arrive with it. Revenue Memorandum Circular (RMC) 15-2025 announced version 7.4 with newly created alphanumeric tax codes and updated rates for creditable and final withholding tax. Check the BIR downloadables page before a filing instead of trusting the copy installed on a workstation; an old module can reject a code that is valid on the certificate.

Revenue Memorandum Circular (RMC) 5-2014 lists the conditions that decide whether an alphalist counts as received: valid TINs, no dummy TINs, complete names, no special characters, no lumped entries, and the current module version. A file that fails the upload is treated as not received, and the related expense can be disallowed. The same circular gives five days from the failure notice to resubmit a corrected, complete list. A corrected list has to be complete, not only the changed rows.

The submission channels are eFPS, the eSubmission address, or the email account of the revenue district officer. Keep the validation acknowledgement with the return. An email sent without a returned acknowledgement is not proof that the alphalist was filed, and the gap is usually discovered during an assessment. PwC's summary of RMC 55-2026 puts the penalty for failing to submit or for supplying incomplete information at P1,000 per failure, capped at P25,000 in a calendar year.

Validation is a diagnosis. The repair happens in the table, not in the report.

Where Extraction Stops and Judgment Starts

The tool can put the certificate's values in a table. It cannot decide which quarter to claim, which ATC applies, or whether the payor's alphalist is right. Those are the calls that need the transaction, the counterparty and sometimes the revenue district office.

The boundaries are concrete. ImageToTable.ai does not generate the .DAT file, does not submit to eBIRForms, eFPS or eSubmission, and does not validate a file against BIR records. It does not compute withholding tax, choose an ATC, or tell you whether an expense is deductible. It does not match your table to the ledger or to the other party's QAP. Those are outside the extraction step, and treating them as automatic is how a clean-looking table becomes an unsupported credit.

The judgment calls are equally concrete: whether a late certificate belongs to an amendment or a later return, whether a branch TIN should be a separate row, how to classify a payment that sits between two ATCs, and what to do when the payor's QAP carries a different amount. Take those to a tax adviser or the RDO. That line is where the work splits between a data job and a tax job.

Frequently Asked Questions

What is the difference between SAWT and QAP?

The SAWT lists the withholding agents that deducted tax from your income, and it supports the credit you claim on your return. The QAP lists the payees you deducted from, and it supports your 1601-EQ or 1601-FQ. They describe the same transactions from opposite sides, so a row that is correct on one side can fail to match the other.

Is a BIR Form 2307 the same as a SAWT?

No. A 2307 is the certificate for one payor-payee relationship in a quarter. The SAWT is the consolidated list of those certificates attached to the return. One certificate can supply several alphalist lines because the row unit is counterparty, ATC and month, not one certificate per row.

When is the QAP due, and when is the SAWT due?

The QAP is due with the 1601-EQ or 1601-FQ on the last day of the month following the close of the quarter. The SAWT has no separate date; it is due with the return that carries the credit, such as the 1701Q, 1702Q or 2550Q. Confirm the exact date against the current BIR calendar because weekends and holidays move it.

Can I prepare a SAWT from scanned or photographed 2307s?

Yes. The certificate is the source document, and a scan or phone photo carries the same fields as an eBIRForms PDF. Extract the values into a table first, then key them into the module or feed your accounting system. The module still needs structured entries or a .DAT file; it does not read the image for you.

Why does the alphalist reject a TIN that looks correct on the certificate?

Check the last five digits. A 14-digit TIN includes a branch code, so a head office TIN and a branch TIN can share the first nine digits and still be different counterparties. Also check for leading zeros lost to a numeric cell, a registered name with a special character, and a dummy TIN. If your row matches the certificate exactly, the payor's QAP may be carrying a different TIN.

Does ImageToTable.ai submit the SAWT or generate the .DAT file?

No. It extracts the certificate fields into Excel, CSV or JSON. It does not generate the .DAT file, validate against BIR records, or submit through eBIRForms, eFPS or eSubmission. Those steps stay with the Alphalist Data Entry and Validation Module and your filing process.

What should I do with a 2307 that arrives after I filed?

Do not force it into whichever quarter is still open. The credit needs its supporting certificate, so the route is an amendment or a claim in the correct return, and the right route depends on the return and the timing. Ask your tax adviser or the RDO before changing a filed position.

The certificate proves that tax was withheld. The alphalist is the argument that you are entitled to the credit, and the argument only holds when the period, the identity and the money agree, on both sides. Build the table first, then spend the time you saved on the matches that need a person.