Converting a POS Sales Export Into a BIR DAT File for RELIEF SLSP: A Retail and Restaurant Walkthrough
A POS (Point-of-Sale) or CRM (Cash Register Machine) sales export lists one row per Official Receipt (OR) or transaction, but RELIEF SLSP (Summary List of Sales and Purchases) needs one row per buyer for the quarter — so the export has to be aggregated by buyer TIN before it can become a valid DAT file. This guide walks a retail store or restaurant through that aggregation step, which QuickBooks or plain-Excel RELIEF workflows on this site don’t need to cover in the same way.
Turn Your POS Export Into a Filing-Ready DAT File FREE →This guide assumes you already know RELIEF SLSP applies to your business and covers only the POS/CRM-specific conversion step. For the underlying filing obligation, see Who Must File RELIEF SLSP?; for the general spreadsheet-to-DAT process once your data is already in the right shape, see How to Convert Excel to BIR DAT File for RELIEF SLSP.
Why doesn’t a POS sales export already match the RELIEF SLSP layout? #
A POS or CRM sales export is built to reconcile daily cash drawers and receipt sequences, so it records one line per Official Receipt or transaction — not one line per buyer. A busy restaurant or retail counter can generate dozens or hundreds of these per-receipt rows a day, almost all of them walk-in cash sales with no buyer name or TIN attached at all, since a POS system has no reason to capture that for a cash customer.
RELIEF SLSP works the opposite way: it reports by counterparty (buyer), not by individual receipt. A VAT-registered seller’s Summary List of Sales is expected to consolidate repeat business with the same buyer into one line for the quarter, not list every invoice separately — the same consolidation principle covered for accounting-software exports in How to Convert QuickBooks or Xero Data Into a BIR DAT File, but sharper here because a POS export starts from hundreds of anonymous receipt rows rather than a handful of named vendor ledgers.
What does a typical POS/CRM sales export look like? #
Most POS and CRM systems export a flat transaction log — one row per OR number, with a timestamp, amount, and payment method, but rarely a buyer name or TIN unless the cashier manually entered one for a charge or credit account. A restaurant’s or retail store’s raw daily export (fictional data) typically looks like this:
| OR No. | Date | Buyer / Account | Gross Amount | VAT (12%, included) | Payment Type |
|---|---|---|---|---|---|
| 10456 | 2026-07-03 | Walk-in | ₱450.00 | ₱48.21 | Cash |
| 10457 | 2026-07-03 | Walk-in | ₱1,120.00 | ₱120.00 | Cash |
| 10458 | 2026-07-03 | Metro Catering Supplies Corp. | ₱38,000.00 | ₱4,071.43 | Charge |
| 10459 | 2026-07-04 | Walk-in | ₱680.00 | ₱72.86 | GCash |
Every receipt is a separate row, buyer names are blank for nearly all of them, and TINs almost never appear — none of which matches what a RELIEF SLSP row needs.
How do POS export columns map to RELIEF SLSP DAT fields? #
Mapping a POS export to RELIEF SLSP means matching each per-receipt column to the per-buyer field it eventually rolls into, and flagging which fields — TIN above all — the POS system never captured and have to be sourced separately. The table below shows the typical correspondence.
| POS/CRM export field | RELIEF SLSP DAT field it feeds | Notes |
|---|---|---|
| OR No. / Transaction ID | (not a DAT field — used only to count transactions per buyer) | Needed to determine regular-buyer status (6+ transactions), not carried into the final row |
| Buyer / Account name (if captured) | Registered Name | Blank for most walk-in rows; populated for charge/credit accounts |
| TIN (rarely in POS exports) | TIN | Must be sourced from the buyer’s Certificate of Registration or billing file for any buyer you itemize — a POS system almost never stores this |
| Gross Amount | Taxable Sales (Net of VAT) + Output Tax | Must be split into the VAT-exclusive amount and the 12% output VAT before entry — POS exports commonly show VAT-inclusive gross only |
| Date | (used to confirm the transaction falls in the filing quarter) | Not a standalone DAT column, but required to scope which receipts belong in the quarter |
| Payment Type | (not used) | Cash, charge, or e-wallet distinction is irrelevant to RELIEF SLSP, which reports by buyer, not by payment method |
How do you convert a POS sales export to a RELIEF SLSP DAT file? #
Converting a POS export means aggregating hundreds of per-receipt rows into per-buyer totals first, then running that aggregated file through the same validation and DAT-generation process any RELIEF SLSP file uses. The aggregation step is what makes this source different from a QuickBooks ledger or a hand-built Excel sheet.
- Export the full transaction log for the quarter from your POS or CRM system — one row per OR/receipt, including date, buyer/account name where captured, and gross amount.
- Split gross amounts into taxable sales and output VAT. If your export shows VAT-inclusive gross, divide by 1.12 to get the net taxable amount, then compute 12% output VAT on that net figure.
- Identify your regular buyers — count transactions per named account (not per receipt) across the current and prior year; any buyer with six or more qualifies, per RMO No. 4-2003 (see below).
- Identify your casual buyers — any single transaction of ₱100,000 or more, even from a buyer with no repeat history.
- Pull the TIN for each regular and casual buyer from their Certificate of Registration, a recent Official Receipt they issued you, or your own billing records — POS systems rarely store this, so it has to be sourced separately.
- Sum every remaining transaction — the walk-in volume that is neither regular nor casual — into a single aggregate row with no individual buyer name or TIN required.
- Upload the resulting per-buyer file to the RELIEF module in BIR Online Tools, review the validation preview for TIN and amount errors, and generate the DAT file for submission with BIR Form 2550Q.
Which buyers must be itemized, and which can stay aggregated? #
RMO No. 4-2003 draws the line between buyers who must be itemized by name in the Summary List of Sales and those who can be folded into a single aggregate figure — and this is exactly the distinction a POS export’s hundreds of walk-in rows are built for. The order defines a regular buyer this way:
“Regular buyers/customers shall refer to buyers/customers engaged in business or exercise of profession with whom the taxpayer had transacted at least six (6) transactions in the previous year or current year, regardless of amount of sale per transaction.”
And a casual buyer as one who falls outside that definition but crosses a separate peso threshold:
“Casual buyers/customers refer to buyers/customers who are engaged in business or exercise of profession with individual purchase/transaction amounting to one hundred thousand pesos (P100,000) or more but did not qualify as regular buyers/customers.”
Both quotes are from Revenue Memorandum Order (RMO) No. 4-2003, issued under the Summary List framework of Revenue Regulations No. 8-2002. For the full breakdown of this rule with a hardware-store example, see Regular vs. Casual Buyer in Your RELIEF SLSP.
| Buyer type in a POS export | RELIEF SLSP treatment |
|---|---|
| Walk-in, cash/e-wallet, no repeat pattern, no single sale near ₱100,000 | Aggregated into one combined row — no name or TIN |
| Repeat corporate/institutional account with 6+ orders in the current or prior year | Itemized by name and TIN — a regular buyer, regardless of per-order amount |
| One-time buyer whose single transaction hits ₱100,000 or more | Itemized by name and TIN for that transaction — a casual buyer |
Worked example: a restaurant’s Q3 POS export, aggregated by buyer #
A small restaurant’s daily POS export is almost entirely walk-in cash transactions, with a handful of corporate catering accounts that recur often enough — or bill large enough — to require their own RELIEF SLSP rows. All names, TINs, and figures below are fictional.
The restaurant’s Q3 2026 (July–September) POS export contains 40 walk-in transactions per day, averaging ₱600–₱1,500 each, paid in cash or e-wallet, with no buyer name captured — a volume that would be unworkable to itemize receipt by receipt. It also shows three corporate catering clients who place recurring orders billed on account:
- Metro Catering Supplies Corp. — 9 separate orders across the quarter, ranging from ₱25,000 to ₱42,000 each, totaling ₱310,000. With 9 transactions, this buyer crosses the 6-transaction regular-buyer threshold, so every one of its orders is itemized under its name and TIN — even though no single order alone reached ₱100,000.
- Island Business Hotel — a single large catering order for a corporate event, billed at ₱135,000 in one transaction, with no other orders that quarter. That one transaction exceeds ₱100,000, making Island Business Hotel a casual buyer for that transaction — itemized by name and TIN even though it’s a one-off relationship.
- Greenfield Realty Office — 3 small catering orders during the quarter, ₱8,000 to ₱12,000 each, totaling ₱28,000. With only 3 transactions and no single order near ₱100,000, this buyer fails both the regular-buyer and casual-buyer tests, so its orders fold into the aggregate walk-in total rather than getting a named row — the same treatment as the cash customers.
| Buyer | Transactions this year | Largest single transaction | RELIEF SLSP treatment |
|---|---|---|---|
| Metro Catering Supplies Corp. | 9 | ₱42,000 | Itemized (regular buyer — 6+ transactions) |
| Island Business Hotel | 1 | ₱135,000 | Itemized (casual buyer — ≥₱100,000) |
| Greenfield Realty Office | 3 | ₱12,000 | Aggregated with walk-in volume |
| ~3,600 walk-in POS transactions (40/day × ~90 days) | 1 each, no repeat | Under ₱1,500 | Aggregated into one combined row |
The restaurant’s Summary List of Sales for the quarter ends up with two itemized rows — Metro Catering Supplies Corp. and Island Business Hotel, each with its own TIN and quarterly total — plus one aggregate row combining Greenfield Realty Office’s small catering orders and the thousands of walk-in POS receipts. That is the entire point of aggregating by buyer before conversion: the POS export’s thousands of rows collapse into a handful of RELIEF SLSP lines, instead of an unfiled (or unworkable) attempt to list every OR number by hand.
Frequently asked questions #
Can I upload my POS or CRM sales export directly to a RELIEF SLSP converter? #
No. A POS or CRM sales export lists one row per Official Receipt or transaction, while RELIEF SLSP requires one row per buyer (counterparty) for the quarter. The export has to be aggregated by buyer TIN first — grouping repeat and large one-off buyers into single rows and summing everyone else into an aggregate total — before it matches the BIR’s Alphalist layout.
Do I need to list every POS receipt separately in my RELIEF SLSP DAT file? #
No. Under RMO No. 4-2003, only regular buyers (six or more transactions with you in the current or prior year) and casual buyers (a single transaction of ₱100,000 or more) need to be itemized by name and TIN. Smaller, one-off walk-in sales from a POS export can be summed into a single aggregate row instead of listing each receipt.
My POS export has no TIN column for walk-in customers — is that a problem for RELIEF SLSP? #
Not for the aggregate row. Walk-in buyers who are neither regular nor casual buyers under RMO No. 4-2003 are reported as a single combined figure with no individual TIN required. A TIN is only needed for the buyers you itemize by name — typically repeat corporate or institutional accounts whose TIN you already have on file from their Official Receipt or billing information.
How do I know which POS customers count as regular buyers for RELIEF SLSP? #
Count transactions per buyer, not per receipt line, across the current and prior year. A buyer who placed orders with you at least six times in that window is a regular buyer under RMO No. 4-2003 and must be itemized regardless of how small each order was — a pattern most POS systems can surface by filtering or pivoting the export by customer name or account.
What’s different about converting a POS export compared to a QuickBooks or Excel-built RELIEF SLSP file? #
A QuickBooks or hand-built Excel file is usually already organized close to one row per counterparty. A POS or CRM export is the opposite — one row per Official Receipt or transaction, often hundreds per day — so the extra step unique to this source is aggregating many per-receipt rows into the per-buyer rows RELIEF SLSP actually requires, rather than just remapping column headers.
Summary #
A POS or CRM sales export is the one common source format that doesn’t already resemble a RELIEF SLSP file, because it reports by receipt instead of by buyer — the opposite of what the BIR’s Summary List of Sales requires. The fix is a buyer-level aggregation pass before conversion: count transactions per buyer to find regular buyers (6+ in the current or prior year), flag any single transaction of ₱100,000 or more as a casual buyer, source TINs for both groups since the POS system rarely stores them, and sum everything else into one aggregate row. Once that aggregation is done, the rest of the process is identical to any other RELIEF SLSP conversion — see How to Convert Excel to BIR DAT File for RELIEF SLSP for the validation and DAT-generation steps, and Who Must File RELIEF SLSP? for whether your business is required to file at all.