How to Prepare SLSP From Invoices for Your BIR 2550Q

The SLSP is the pair of quarterly summary lists, the Summary List of Sales and the Summary List of Purchases, that a VAT-registered taxpayer files for the same quarter as BIR Form 2550Q. BIR's own materials often call it the SLSPI, because importations is a third list. It is due within 25 days after the close of the taxable quarter, the same deadline as the return itself, and it reaches BIR as .DAT files emailed to [email protected].

Every row carries the counterparty's BIR-registered name and TIN, the transaction amount placed in the correct classification column, and the tax broken out, with purchases splitting input tax between creditable and non-creditable. Classification is structural rather than descriptive: there is no free-text field where you say what the sale or purchase was.

Revenue Regulations No. 1-2012 made SLSP submission mandatory for every VAT-registered taxpayer effective 1 January 2012, regardless of turnover. The PHP 2,500,000 and PHP 1,000,000 quarterly thresholds still widely quoted are the pre-2012 test, and they no longer determine who files.

Working out how to prepare SLSP from invoices is where the available guidance runs out. Accounting systems generate the lists from transactions already recorded in their ledger. Spreadsheet-to-.DAT converters take an already-structured Excel file and reformat it. Tax-firm explainers recite the thresholds, the deadline, and the field list, then stop. Each of them assumes the invoice data is already keyed in somewhere. If you are holding a quarter of sales invoices and supplier invoices as PDFs and scans, with no system that already contains them, none of that addresses the step you are actually on.

That step has a well-defined target: a spreadsheet whose columns match the BIR schema exactly, one row per invoice. From there the table becomes a .DAT file, either by keying it into BIR's RELIEF Data Entry module or by converting the spreadsheet directly, and BIR's own Validation Module checks the result before you email it.

Who Files, By When, and What a Late or Wrong List Costs

Revenue Regulations No. 1-2012 amended Section 4.114-3 of RR No. 16-2005 to require quarterly SLSP submission from all VAT-registered taxpayers, effective 1 January 2012. There is no sales figure and no purchase figure below which a VAT-registered taxpayer is excused. If you are registered for VAT, you file.

The pre-2012 regime is worth knowing only so you can recognize it when you meet it. Back then the tests were quarterly sales or receipts net of VAT above PHP 2,500,000 for the Summary List of Sales and quarterly purchases net of VAT above PHP 1,000,000 for the Summary List of Purchases, and once a taxpayer crossed a threshold it was bound to submit for the three succeeding quarters whether or not those quarters crossed it. Those figures are still circulating on tax-explainer pages, in downloadable templates, and in the working notes of firms that have not revisited the rule in a decade. A bookkeeper who trusts them will skip a filing they owe.

The deadline is the 25th day of the month following the close of the taxable quarter, the same date the 2550Q falls due. Note the word taxable: the reckoning runs from your own quarter-end, so a taxpayer on a fiscal year does not default to the calendar quarters. You will also see it widely stated that eFPS-enrolled and Large Taxpayer filers have until the 30th day. That claim is common enough in practice to mention but does not trace to a clear BIR issuance, so confirm the applicable date with your assigned Revenue District Office rather than planning around it.

One point of housekeeping, because it still trips people up: monthly VAT filing on BIR Form 2550M stopped being mandatory on 1 January 2023 under the TRAIN Law, and RMC No. 52-2023 made the form optional. The 2550Q is the recurring return, and the SLSP is filed for the same quarter through its own channel.

Quarters with nothing to report

Because RR No. 1-2012 attaches the obligation to VAT registration rather than to transaction volume, there is no de minimis carve-out, and the standard practice is to submit a nil list for a quarter with no reportable transactions. Be aware that RDO practice on nil submissions is not uniform, and that the pages telling you a specific circular mandates it are generally citing the wrong issuance. Ask your own RDO how they want a zero SLSP handled, and keep the answer with your working papers.

What errors actually cost

Section 250 of the NIRC imposes PHP 1,000 for each failure to file an information return, statement, or list, capped in aggregate at PHP 25,000 per calendar year. The Revised Schedule of Compromise Penalties in RMO No. 7-2015 applies this to the SLSP, and the detail that matters is how the counting works: failure to supply correct and accurate information for each buyer or seller is a separate punishable act. Fifty rows with a wrong or missing counterparty TIN are not one mistake. They accumulate against the same annual cap, and repeat offenses are treated as willful failure, which is not subject to compromise at all.

The exposure most practitioners feel is larger than the penalty schedule, though. BIR cross-matches the summary lists filed by both sides of a transaction. When your purchases list carries a supplier's name or TIN that does not agree with what that supplier reported, the corresponding input VAT is a candidate for disallowance on assessment. That is why the data-cleaning step later in this article is worth more time than it looks like it deserves.

The Exact Columns Each List Needs

Section 4.114-3 of RR No. 16-2005 sets out what each row must contain. This is the schema BIR's RELIEF module implements, and it is the specification your extracted spreadsheet has to match. Build it once and you can reuse it every quarter.

Summary List of Sales, one row per buyer transaction:

Column	What goes in it
BIR-registered name of buyer	The buyer's registered name, for buyers engaged in business or the exercise of a profession
TIN of buyer	Required for sales subject to VAT
Exempt sales	Amount, for transactions exempt under Section 109 of the NIRC
Zero-rated sales	Amount, for exports and other zero-rated transactions
Sales subject to VAT	Amount exclusive of VAT
Sales subject to final VAT withheld	A legacy column for government sales; see the note below before using it
Output tax	The VAT on the taxable sales

Summary List of Purchases, one row per supplier transaction:

Column	What goes in it
BIR-registered name of seller	The supplier's or service provider's registered name
Address of seller	The supplier's registered address
TIN of seller	As registered, branch code included
Exempt purchases	Amount, including purchases from non-VAT suppliers
Zero-rated purchases	Amount, for zero-rated transactions
Purchases of services	Taxable services, net of VAT
Purchases of capital goods	Taxable capital goods, net of VAT
Purchases of goods other than capital goods	Taxable goods that are not capital goods, net of VAT; the module treats this as the residual
Creditable input tax	Input VAT you are entitled to claim
Non-creditable input tax	Input VAT you cannot claim, such as input attributable to exempt sales

A note on the government column. RR No. 16-2005 still prescribes a column for sales subject to final VAT withheld, meaning sales to government. That label is a leftover. Since 1 January 2021 the 5% VAT that government agencies withhold has been creditable rather than final, under the TRAIN Law's amendment to Section 114(C) of the NIRC, so it is no longer a settled tax on those sales. Report government sales as ordinary taxable sales in your list. If your RELIEF module still presents a government or final-VAT field, ask your RDO how it wants that field populated rather than guessing, because BIR has never formally conformed the SLSP schema to the change.

Classification is a column, not a description

This is where most self-built spreadsheets break. There is no field in either list where you write what the sale or purchase was. The regulation does not ask for a nature-of-transaction description, and the RELIEF module has nowhere to put one. Classification happens by placement: the amount goes into the exempt column, the zero-rated column, or the appropriate taxable column, and the module derives taxable amounts as the residual of the gross invoice amount less the exempt and zero-rated portions.

A working file with a single Amount column and a text label reading "services" or "VAT exempt" alongside it will not map cleanly into the module. You will end up re-splitting it by hand at the point where you are least able to afford the time. Split the amounts into their destination columns during extraction, not afterwards.

Note too that the sales list reports amounts exclusive of VAT with output tax stated separately. Supplier and customer invoices in the Philippines frequently show a single VAT-inclusive total, which means the row cannot be populated until that figure is broken apart. If your documents are inconsistent about this, working the net and VAT back out of a VAT-inclusive invoice total covers the arithmetic and how to apply it across a batch.

The third list

The Summary List of Importations applies to VAT-registered taxpayers that import goods, and the same regulation defines its fields: the import entry declaration number, the assessment or release date, the date of importation, the name of the seller, the country of origin, the dutiable value, all charges incurred before release from Customs custody, the landed cost split between its exempt and taxable portions, the VAT paid, and the official receipt number and date of that payment.

Its source documents are import entries and Customs paperwork rather than supplier invoices, so it sits outside the extraction workflow the rest of this article describes. If you import, you build it separately, from a different pile of documents.

What limits the data you can extract

Your extraction is bounded by what your source documents actually carry. A sales invoice that omits the buyer's TIN cannot supply one, and a supplier invoice that shows no VAT breakdown forces you into a calculation or a query. Before you assume the fields are recoverable, it is worth checking your documents against what a valid Philippine sales invoice must contain after the EOPT Act, since the required content changed and older document templates in circulation do not always meet it.

Across both lists, the counterparty's BIR-registered name and TIN are the load-bearing identifiers. Everything else is an amount that can be recomputed or corrected from the invoice; those two are how BIR matches your list against somebody else's. The RELIEF module also captures a counterparty's address the first time it encounters them, which is why the purchases list carries an address column while the sales list does not.

---

Extracting a Quarter of Invoices Into the SLSP Columns

A quarter's documents rarely arrive tidy. Some supplier invoices are native PDFs, some are scans of varying quality, a few are phone photos forwarded by a branch. Layouts differ from supplier to supplier, several invoices are sometimes concatenated into a single PDF, and the batch is padded with email cover sheets and remittance advices that belong in none of it.

Run the two lists as two separate extractions. The sales invoices produce the sales list columns, the supplier invoices produce the purchases list columns, and the schemas are different enough that trying to force both through one pass produces a table you have to unpick afterwards. Two batches, two prompts, two output files that map one-to-one onto the two lists you owe.

Specify the columns, not just the fields

The instruction that drives the extraction should name the exact output you want, because named fields become the column headers. For the purchases batch, that looks like this:

I'm preparing the BIR Summary List of Purchases for our quarterly VAT return.

Extract, one row per supplier invoice:

• Supplier BIR-Registered Name (prefer the registered name in the footer over the trading name in the header)
• Supplier Address
• Supplier TIN (extract as text, keep the branch code, do not drop leading zeros)
• Invoice Date
• Exempt Purchases
• Zero-Rated Purchases
• Purchases of Services
• Purchases of Capital Goods
• Purchases of Goods Other Than Capital Goods
• Creditable Input Tax
• Non-Creditable Input Tax

Rules:

• All amounts are net of VAT. If an amount does not apply to a row, set it to 0 rather than leaving it blank.
• If an invoice shows only a VAT-inclusive total, extract the total as shown and add a column marking that row VAT-inclusive.
• Skip email cover sheets, remittance advices, and statement summary pages.

Two details in there do real work. Opening with what the batch is for, rather than only listing fields, gives the extraction the context to handle edge cases sensibly, which on a quarter of mixed supplier documents is most of the job. And keeping the column order as the schema has it means nothing needs rearranging before it goes downstream.

Two output properties matter more here than they would on an ordinary AP export. Values come back natively typed in Excel, so the amount columns total and reconcile without a cleanup pass. And every row carries a reference to its source file and page number, so when a figure is questioned during encoding, or a year later during an assessment, you can be looking at the original invoice in seconds rather than searching a folder. On a list where a wrong counterparty row is a separately punishable act, that traceability earns its keep.

Where a value is uncertain, it is flagged as Review Needed with an explanation of what to check, rather than guessed silently. That distinction matters on a compliance schedule: an unflagged wrong TIN propagates into the .DAT and into BIR's cross-matching, while a flagged one costs you thirty seconds.

Because the SLSP is a quarterly obligation over a stable set of counterparties, the instruction is worth saving and reapplying. Running the same prompt every quarter is what keeps supplier names and column structures consistent between filings, which in turn is what makes the master-list reconciliation in the next section cheap instead of a fresh exercise each time.

Where the tool stops

With Invoice Data Extraction you can extract a whole quarter of sales and supplier invoices into one BIR-shaped spreadsheet, uploading the batch, describing the columns above, and downloading the result as XLSX, CSV, or JSON. Batches run to 6,000 files, and a single PDF can be up to 5,000 pages, so the concatenated-invoice files and the scanned bundles do not need splitting up first. Native PDFs, scans, JPGs, and PNGs all go into the same batch.

What comes back is a structured spreadsheet matching the BIR column schema. It is not a .DAT file. The product does not generate .DAT files, submit anything to BIR, or check a TIN against BIR's taxpayer database. You take that spreadsheet into an accredited third-party converter, or key it into BIR's RELIEF module, and the resulting file goes through BIR's Validation Module before it is emailed.

That boundary is worth stating clearly because it changes how you should think about the converter tools. AccountingMage, bir-excel-uploader, and the rest sit downstream of the extraction step rather than replacing it. Every one of them begins from a structured spreadsheet that somebody still has to produce, and producing it is the part that takes the week. The same is true of the accounting platforms that advertise SLSP generation: they generate from transactions already recorded in their ledger, which means the encoding happened, just earlier and by hand.

If you want the underlying technique rather than the BIR-specific application of it, converting a batch of PDF invoices into Excel rows covers the general mechanics, prompt structure, and batch handling in more depth.

Fix TINs and Registered Names Before You Encode

The SLSP has to carry the counterparty's BIR-registered name, which is often not the name printed across the top of the invoice. A supplier trading as one brand may be registered under a corporate name that appears only in the footer, or in the fine print beside the ATP details, or nowhere on the document at all. The same happens on the sales side with customers who order under a division name.

Extraction captures what the document says. That is the correct behavior, and it is why this is a reconciliation step rather than something you can solve with a better prompt. The registered name lives in BIR's records, not on the invoice, so the fix is a lookup against data you maintain, applied after the extraction and before the encoding.

What the module actually rejects

The recurring failure modes are narrow and predictable:

• Invalid or malformed TINs, including placeholder values keyed as strings of zeros where nobody could find the real number
• Registered names that do not match BIR's records for the given TIN
• Missing counterparty TINs, most often on the purchases list
• Duplicate or double-entered rows, usually from an invoice captured twice
• Inactive taxpayer records, where the counterparty has closed or deregistered
• Misclassified transactions, where an amount sits in the wrong column
• Header mismatches, where the reporting TIN or period in the file does not agree with the submission

Most of these are visible in the spreadsheet before the file ever reaches the module, which is the entire argument for cleaning at the spreadsheet stage rather than debugging validation errors under deadline.

The TIN field itself is moving

TIN handling is a formatting problem as much as a lookup problem, and it changed recently. RMC No. 36-2026, which released eBIRForms Package Version 7.9.6.0 on 28 April 2026, increased the character field length of the TIN Branch Code from three digits to five digits across all tax returns.

If your counterparty records, spreadsheet templates, or lookup tables were built around a three-digit branch component, they need checking. Two practical consequences follow for the extraction itself. Capture TINs as text rather than as numbers, so a leading zero in a branch code survives the trip into Excel instead of being silently dropped. And capture the branch code in full rather than truncating to the length your old template expected, because a truncated branch code is a mismatch even when the nine-digit base is correct.

When prevention fails, the remedy is expensive

Simple problems you fix in your own file. The hard ones you cannot. A registered name that disagrees with BIR's records, a duplicate TIN, or an inactive taxpayer record sits in the counterparty's registration data, not in your spreadsheet, and correcting it typically means the counterparty filing BIR Form 1905 to update their own details, or somebody making a walk-in visit to the assigned Revenue District Office. Online TIN verification through ORUS helps with straightforward checks but does not resolve the tangled cases.

That is a day of someone's time, on a deadline, for a problem that a lookup would have caught in the first hour.

Keep a master counterparty list

The practice that makes this manageable is a maintained master list of verified counterparty TINs and BIR-registered names, one row per customer and supplier. It is unglamorous and it compounds.

Each quarter, match the extracted counterparty names and TINs against it. Exact matches pass straight through. Rows that do not match, or that match on TIN but disagree on name, get queued for verification before anything is encoded. Every newly verified counterparty is added to the list, so the unmatched queue shrinks each quarter until it contains only genuinely new trading partners. For a firm handling several client entities, the list is per entity but the discipline is the same.

The classification edge cases

A few transaction types cause encoding problems even when the names and TINs are clean:

• Purchases from non-VAT and VAT-exempt suppliers still belong on the list. They carry no creditable input tax and their amounts go in the exempt purchases column. Dropping them because there is no input VAT to claim is a common and avoidable error.
• Zero-rated sales need their own column and must not be folded into taxable sales, which would overstate your output tax against the return.
• Taxable purchases not qualified for input tax credit go under non-creditable input tax rather than being reported as creditable and corrected later.

Handle these as rules in the extraction where the invoice carries enough information to decide, and as a review queue where it does not.

Turning the Spreadsheet Into a DAT File and Submitting It

First, download the right utility. Two BIR products have confusingly similar names, and only one of them is yours. The Alphalist Data Entry and Validation Module handles the alphalists for BIR Forms 1604-C, 1604-E, and 1604-F. The SLSP belongs to the RELIEF Data Entry and Validation Module, currently version 2.3, listed separately on the BIR downloadables page. People lose an afternoon to this more often than they admit.

The RELIEF Data Entry module has no spreadsheet import. Its screens are Sales, Purchases, and Importations, one transaction added at a time, and its only import function moves its own database between machines. Take your extracted spreadsheet to that module and you will be keying it in by hand, which is precisely the outcome the extraction was meant to avoid.

BIR's own rules let you skip the keying

Most guidance never mentions this. RMO No. 4-2003 provides that the quarterly SLSP may be submitted in electronic format "using either excel format, taxpayer's own extract program or the data entry module developed by the Bureau," and that data produced by Excel or your own extract program must then be validated using the validation module BIR developed. The data entry module is one of three permitted routes, not the mandatory one.

So the path from a structured spreadsheet runs like this: map the spreadsheet into the prescribed .DAT record layout, using an accredited third-party converter or your own extract program, then run the output through the BIR Validation Module. The module checks the file and appends a serial number, and what you email is the module's output rather than the file you fed it. The record layout itself is prescribed by RMC No. 24-2002, which is the practical reason to use an established converter rather than write your own mapping against a specification that is awkward to obtain.

This also puts the converter tools in their proper place. Using one is not a workaround: BIR's rules explicitly contemplate an Excel-based route, and the only hard requirement is that the .DAT passes validation.

Sending it

Submission is by email to [email protected], the channel RMC No. 19-2015 prescribes for SLSP alongside SAWT and MAP files. Send the .DAT as the Validation Module produced it, filename and appended serial unchanged.

BIR has not published a single mandatory subject-line format for the SLSP. The formats you will find quoted online are mostly borrowed from alphalist guidance, which is a different submission with different rules, and RDOs differ in what they want in the subject line and body. Ask yours once, write the answer down, and use it every quarter.

BIR replies with a validation report email. That reply is your proof of filing, and it is the only evidence you will have that the submission was accepted rather than silently rejected. File it with the quarter's working papers alongside the spreadsheet it came from, so the chain runs from the original invoice through the extracted row to the accepted file.

Filing the 2550Q does not file the SLSP

This is worth stating plainly because it is expensive to get wrong. Submitting the 2550Q through eFPS does not discharge the SLSP obligation. eFPS does not accept SLSP uploads at all. eAFS is a different facility again, for financial statement and income tax return attachments, and it is not where the summary lists go. The SLSP is a separate submission through a separate channel, and a taxpayer who has filed the return on time can still be sitting on an unfiled attachment.

If your system already generates the file

Taxpayers running a BIR-registered Computerized Accounting System, or accredited third-party software, may have the .DAT produced by that system directly. That route is open to you only if the system is registered for the purpose, which carries its own compliance requirements. BIR Computerized Accounting System registration requirements covers what registration involves and when it is worth pursuing.

Turning the Same Extraction Into Your 2550Q Figures

The two spreadsheets you built for the summary lists are also your VAT working papers, and this is the part of the routine that pays for the setup.

The sales extraction is an output VAT schedule from sales invoices. Its column totals go straight onto the return: taxable sales, zero-rated sales, exempt sales, and the output tax. The purchases extraction is an input VAT schedule from supplier invoices, and its totals give you the input tax claimed, with the services, capital goods, and other goods split already in place because the SLSP schema demanded it. Nothing needs re-keying, because the values came back natively typed and the columns are already the ones the return asks about.

Sales to government are the one place where the mapping is not one-for-one. On the April 2024 version of the form they go into VATable sales at Item 31 like any other taxable sale, while the 5% the agency withheld is claimed separately as creditable VAT withheld at Item 16, supported by Part V Schedule 3 and the BIR Form 2307 certificates your government clients issue. If you are working from guidance that routes government sales to a Schedule 8, or to Item 23C or 26D, that guidance was written for the February 2007 form and no longer matches what you are filing.

There is a compliance reason to build both from one dataset, not merely a tidiness one. BIR's systems compare the summary lists against the return. A variance between the two invites a query, and the most common cause of that variance is exactly what happens when they are prepared separately: the return is built from one set of working papers, the attachment from another, and the two drift by a few invoices that arrived late or were reclassified in one file and not the other. One extraction feeding both removes the drift by construction. When a figure is questioned, the source file and page reference on the row takes you to the invoice behind it.

Capital goods are the one place where the two documents genuinely diverge, and it is a timing divergence rather than a data one. The purchases list reports the capital goods acquired in the quarter, while the input tax you may actually claim on the return can be spread over a period rather than taken in full, depending on the acquisition and the rules in force. Keep the SLSP column reporting what you bought, and confirm your own amortization position against current guidance before carrying the figure onto the return.

The summary lists are not your only quarterly attachment. If you withhold on supplier payments or receive certificates from customers who withhold on yours, the same quarter brings a separate submission built from a different document set through a different BIR system. Preparing your SAWT and QAP from BIR Form 2307 certificates is the same document-to-schema job on the withholding side, and it is worth batching the two exercises together while the quarter's paperwork is already open in front of you.

---

What Is Changing, and What Still Is Not

The SLSP has not been folded into an online VAT return. The BIR Digital Transformation Roadmap set out that intention, and the plan has been discussed widely enough that practitioners sometimes assume it has happened, but no Revenue Memorandum Circular has implemented it. The email-to-esubmission routine remains the operative channel, and superseding it would require a formal issuance. Watch for that circular rather than assuming integration has already arrived.

Adjacent developments are easy to mistake for it. RMC No. 53-2026 launched a BIR Taxpayer Portal, which is a pilot restricted to Large Taxpayers Service registrants, and a viewing facility for registration details, returns filed, and payments rather than a submission channel for anything.

The changes that will actually affect your data arrive quietly, in the offline package. The eBIRForms version number is the practical signal to track, because field-level changes land there without a headline. The TIN branch code expansion is the current example, and it is the kind of change that breaks a template built two years ago while nothing in the compliance calendar warns you about it. Checking the release notes when a new package version appears takes ten minutes a quarter.

The wider direction is toward transaction-level reporting: statutory submissions that ask for a schedule of individual documents rather than a set of aggregate figures. The Philippines has required this for VAT since long before it became fashionable elsewhere, and other jurisdictions are converging on the same shape from different starting points. The same document-to-statutory-schema routine applied to Ireland's Intrastat RPF CSV is recognizably the same job with a different column list and a different upload target. Whichever format an authority settles on, the durable capability is being able to turn a folder of source documents into a clean, per-document dataset, because that is the input every one of these regimes assumes you already have.