Common RELIEF SLSP Upload Errors and How to Fix Them Before eSubmission

Most RELIEF SLSP upload errors trace back to five causes: a VAT amount that doesn’t match its computed value, inconsistent VAT rates or return periods within the same file, an invalid or placeholder TIN, a missing buyer or vendor name, and — for purchases — a taxable amount that doesn’t equal its component columns. Each one stops a Summary List of Sales or Purchases from generating a clean DAT file, and each is fixable in the source data before it ever reaches the BIR.

This guide walks through why each error happens and how to fix it. For the underlying thresholds and deadline, see How to Convert Excel to BIR DAT File for RELIEF SLSP; for what happens if a file is late or mismatched after submission, see RELIEF SLSP Deadlines and Penalties.

Why does the output or input VAT amount get flagged? #

A VAT amount error means the output VAT (sales) or input VAT (purchases) entered for a row doesn’t equal the taxable amount multiplied by the VAT rate, rounded to two decimal places. This is the single most common RELIEF SLSP error, because it’s easy to type a VAT figure copied from an invoice rather than recalculating it from the taxable base actually entered in the row.

A worked example: a row lists a taxable sale, net of VAT, of P150,000.00 at a 12% VAT rate. The expected output VAT is ROUND(150,000.00 × 12 / 100, 2) = P18,000.00. If the row instead shows P17,850.00 — perhaps copied from an invoice that applied a discount after VAT was computed, or simply mistyped — the row fails validation even though every other field is correct.

Fix: always compute output or input VAT from the taxable amount and rate actually entered in that row, rather than pasting a VAT figure from a separate source document. A small rounding tolerance (about one centavo) is allowed, but anything beyond that is flagged.

Why does the file reject mixed VAT rates or return periods? #

Every detail row in a single RELIEF SLSP file must share the same VAT rate and the same return period — mixing either one across rows causes the file to fail validation as a whole, not just the affected rows. The return period must also be entered in MM/YYYY format, and the rate must be either 12% (the standard rate) or 10% (the CREATE Act’s temporary reduced rate for the period it applied).

Fix: confirm every row in the sheet belongs to the same taxable quarter before uploading, and don’t combine transactions taxed at different VAT rates in one file — split them into separate filings if a genuine rate difference applies.

Why is my TIN or buyer/vendor name rejected? #

A TIN in a RELIEF file must be exactly 9 digits when provided, with the branch code tracked as a separate value — anything shorter, longer, or containing non-digit characters fails, as does the placeholder value 000000000. Separately, every row needs a way to identify the counterparty: either a registered company name, or both a last name and first name for an individual. A row with neither is rejected outright.

Typical causes:

• A TIN copied from a document still includes dashes, spaces, or a merged branch code
• Excel stripped a leading digit because the TIN column was formatted as a number instead of text
• A buyer or supplier row has a first name but no last name, or vice versa, with no company name to fall back on
• The placeholder “000000000” was left in a row for a walk-in or unidentified counterparty

Fix: format TIN columns as text, strip all non-digit characters, and make sure every row has either a complete registered name or a complete first-and-last name pair — never a partial one.

Do I need one row per transaction, or one per counterparty? #

RELIEF SLSP data is meant to be reported as one consolidated line per counterparty per quarter, not one line per individual invoice. BIR Online Tools’ RELIEF module handles this automatically: it groups every detail row by a matching key of TIN and registered (or first/last) name, sums the exempt, zero-rated, taxable, and VAT columns for each match, and sorts the resulting list alphabetically by counterparty name before generating the DAT file.

This matters even if a spreadsheet lists the same customer or supplier across a dozen separate invoice rows for the quarter — the underlying data doesn’t need to be pre-consolidated by hand, since the conversion step does that automatically. What it does need is consistent identification across those rows: if the same supplier is entered as “ABC Trading Corp.” in one row and “ABC Trading Corporation” in another, or with a slightly different TIN, the tool will treat them as two separate counterparties instead of consolidating them into one line.

Why does a Summary List of Purchases reject a correct-looking taxable amount? #

For the Summary List of Purchases specifically, the taxable amount net of VAT must equal the sum of the services, capital goods, and other-than-capital-goods columns for that row — if those three don’t add up to the taxable total entered, the row fails even when each figure looks right on its own.

If the taxable net of VAT column instead shows P115,000.00 — because one of the three components was updated but the total wasn’t recalculated — the row is rejected. This is a purchases-only rule; the Summary List of Sales doesn’t split the taxable amount into these sub-categories.

Pre-upload checklist #

• Every row uses the same return period (MM/YYYY) and the same VAT rate
• Output VAT (sales) or input VAT (purchases) recalculated from the taxable amount and rate, not copied from a separate document
• TINs formatted as text, digits only, exactly 9 digits, with no placeholder 000000000 values
• Every row has a complete registered name or a complete first-and-last name
• Purchases: taxable net of VAT equals services + capital goods + other-than-capital-goods
• Counterparty names spelled consistently across rows so the same buyer or supplier isn’t split into duplicate entries

How does BIR Online Tools catch these before generating the DAT file? #

The RELIEF module in BIR Online Tools runs these checks — VAT arithmetic, consistent rate and period, TIN format, and required name fields — during upload, surfacing each error against its specific sheet and row before a DAT file is generated. It also performs the counterparty consolidation and alphabetical sorting described above automatically, so a spreadsheet exported straight from an invoicing system doesn’t need to be manually grouped by customer first. For the full column-by-column layout this validation checks against, see How to Convert Excel to BIR DAT File for RELIEF SLSP.

Frequently asked questions #

Why does my RELIEF SLSP file show an output VAT or input VAT error? #

This happens when the output VAT (for sales) or input VAT (for purchases) entered for a row doesn’t equal the taxable amount multiplied by the VAT rate, rounded to two decimal places. Even a one-centavo rounding difference outside a small tolerance will flag the row, so output or input VAT should always be recalculated from the taxable amount rather than typed in separately.

Can a RELIEF SLSP file mix 12% and 10% VAT rates? #

No. A single Summary List of Sales or Summary List of Purchases file must use one consistent VAT rate across every detail row. If some transactions were taxed at a different rate than others in the same quarter, they need to be reconciled to a single rate for that filing or handled as separate submissions, not mixed in one file.

Why does my RELIEF file reject a valid-looking TIN? #

A buyer or supplier TIN in a RELIEF file must be exactly 9 digits (the branch code is tracked separately), and a placeholder like 000000000 is rejected outright. A TIN that’s short, contains extra characters, or was pasted with a branch code merged into the base number will fail this check even if the underlying value is correct once cleaned up.

Do I need to list every transaction with the same customer separately, or can they be combined? #

They should be combined. Multiple transactions with the same buyer or supplier in the same quarter are meant to be reported as one consolidated line per counterparty, not as separate rows per invoice. Leaving them unconsolidated doesn’t necessarily break upload, but it produces a messier file than the BIR’s own cross-matching process expects.

Why does my Summary List of Purchases reject a correct-looking taxable amount? #

For purchases, the taxable amount net of VAT must equal the sum of the services, capital goods, and other-than-capital-goods columns. If those three columns don’t add up to the taxable amount entered, the row fails validation even if each individual figure is accurate on its own.

Summary #

Most RELIEF SLSP upload errors come down to arithmetic and consistency: a VAT amount that doesn’t match its computed value, a return period or VAT rate that isn’t the same across every row, an invalid or placeholder TIN, a missing counterparty name, or — for purchases — a taxable amount that doesn’t equal its component columns. None of these require re-entering the underlying transaction data; they’re formatting and consistency fixes at the source spreadsheet. A converter that checks VAT arithmetic, consolidates counterparty rows, and flags errors before generating the file — like the RELIEF module in BIR Online Tools — catches them at the point they’re cheapest to fix, rather than after a rejected eSubmission.