What does an 'invalid return period' error mean on a SAWT DAT file?

It means the period field in the DAT file does not match the covered period the BIR's Alphalist Data Entry and Validation Module expects for the return type and taxpayer you entered — usually because the period was carried over unchanged from a previous quarter's template, or because it doesn't line up with a fiscal-year accounting period.

Why would a SAWT file from a previous quarter's template cause this error?

Preparers often reuse last quarter's SAWT template to save time, updating the payor rows and amounts but forgetting to update the period field in the file header or settings. The Validation Module checks the period field independently of the data rows, so an unchanged header fails even if every other field is correct.

Does SAWT use a calendar quarter or the taxpayer's own fiscal period?

SAWT's return period always matches the income tax or VAT return it's attached to, which follows the filer's own accounting period — calendar year or an approved fiscal year under BIR Form 1905. A fiscal-year filer whose quarters don't align with the calendar year must enter the period that matches their own fiscal quarter, not the calendar quarter.

Can the same SAWT DAT file cover more than one quarter?

No. Each SAWT DAT file covers exactly one return period, matching the single income tax or VAT return it supports. Certificates received across more than one quarter need to go into separate SAWT files for each corresponding filing, even if they come from the same payor.

What should the period field actually contain?

The period field should reflect the covered period (and, for annual returns, the taxable year) of the specific return — for example, the applicable quarter-end date for a quarterly VAT or income tax return — entered in the date format the SAWT template and Validation Module expect, not simply the date you happen to be preparing the file.

SAWT DAT File Rejected for 'Invalid Return Period': How to Fix It Before Resubmitting

A SAWT DAT file that fails validation with an “invalid return period” error almost always has a period field that doesn’t match the actual quarter or year of the income tax or VAT return it’s meant to support — not a problem with the certificate data itself. The most common cause is a reused template: a preparer copies last quarter’s SAWT file to save time, updates the payor rows, and forgets that the period field in the header or generation settings is still set to the prior quarter.

This guide covers what the return period field actually represents, the specific ways it commonly goes wrong, and how to isolate the fix before regenerating the file. For SAWT basics, see How to Convert Excel to BIR DAT File for SAWT; for other SAWT validation failures, see Common SAWT DAT File Errors and How to Fix Them.

Generate a Correctly Dated SAWT FREE →

Why does the return period field matter so much to the Validation Module? #

SAWT exists to support a specific return for a specific period — the BIR’s Alphalist Data Entry and Validation Module checks that the period field matches what’s expected for the return type before it ever looks closely at the payor rows underneath it, because a SAWT with the wrong period attached is effectively supporting the wrong filing. SAWT itself is governed by Section 2.57.2 of Revenue Regulations (RR) No. 2-98 and RR No. 2-2006, which established it as a mandatory attachment to any income tax or VAT return claiming creditable withholding tax as a credit — the whole point of the file is to tie a specific set of BIR Form 2307 certificates to the one return period those certificates are being claimed against.

The submission mechanism itself is set out in RR No. 2-2015, which amended RR No. 2-2006:

“The SAWT shall be submitted through the applicable modes of submission prescribed under Revenue Regulations No. 1-2014, using the data entry and validation module of the BIR.”
— RR No. 2-2015, Section 2 (amending Section 2 of RR No. 2-2006)

Because of that, the period field isn’t a cosmetic label — it’s the key the Module uses to confirm the file belongs with the return it’s being attached to. A mismatch here fails before the Module even reaches TIN formatting or ATC codes, which is why an “invalid return period” rejection can be confusing: the data underneath can be completely correct and still get rejected over a header field most preparers barely look at.

What actually causes an invalid return period error? #

Three patterns account for most invalid-period rejections, and all three trace back to the file’s header or generation settings rather than the certificate data itself.

Cause	What happens	Fix
Reused template, unchanged period	Last quarter’s SAWT file is copied as a starting point; payor rows are updated but the period setting isn’t	Regenerate the period field (or the generation setting feeding it) to the current filing period before reconverting
Fiscal-year mismatch	A fiscal-year filer enters the calendar quarter instead of their own approved fiscal quarter under BIR Form 1905	Confirm your approved fiscal year-end and enter the corresponding fiscal quarter, not the calendar one
Wrong return type assumed	A period valid for a quarterly VAT return is entered while generating a SAWT meant to support an annual income tax return (or vice versa)	Match the period format and coverage to the specific return the SAWT is attached to for that filing
Straddling certificates split incorrectly	A certificate covering a transaction near a quarter boundary gets filed under the wrong adjoining quarter’s SAWT	Confirm which period the underlying BIR Form 2307 actually belongs to before assigning it to a SAWT period

A SAWT file never covers more than one return period at a time — certificates from two different quarters always need two separate SAWT files, each correctly dated to the return it supports, even when every certificate comes from the same handful of payors.

Worked example: a fiscal-year corporation’s Q2 SAWT #

Cordillera Agri-Processing Corp. operates on a fiscal year ending every June 30, approved through BIR Form 1905, instead of the calendar year. Its bookkeeper, more used to preparing calendar-year filings for other clients, prepares the SAWT supporting the company’s second fiscal quarter — covering October 1 to December 31 — but initially enters the calendar Q4 (October–December, which happens to coincide numerically but is labeled by the bookkeeper’s software as “Q4” rather than the company’s own “FY Q2”).

Field	What the bookkeeper entered	What the return actually needed
Return type	Quarterly income tax return (1702Q)	Quarterly income tax return (1702Q)
Covered period	Calendar Q4 label	Cordillera’s own fiscal Q2 (Oct 1 – Dec 31), entered against its fiscal year-end
Result	Validation Module error: period doesn’t match registered fiscal year on file	—

Because the dates happen to line up, the content of the SAWT file is actually correct — the error is purely that the period label submitted doesn’t match the fiscal-year accounting period the BIR has on file for Cordillera under its approved BIR Form 1905. Re-entering the period against the company’s registered fiscal year, rather than a generic calendar-quarter label, clears the validation error without changing a single payor row.

Summary #

An “invalid return period” error on a SAWT DAT file is almost always a header-field problem, not a data problem — the period has to match the exact return and filing period the SAWT supports, which trips up reused templates and fiscal-year filers most often. Confirm the period against the specific return you’re filing (and your registered accounting period if you’re on a fiscal year) before regenerating, rather than assuming last quarter’s settings still apply.