Payment Records and Tax Reporting for Philippines E-commerce Merchants

2026-10-04 18:00:00

I handle finance and payments operations for a China-based e-commerce brand that started selling into the Philippines a few years ago. When we were small, I treated the payment gateway purely as a plumbing problem: get checkout to work, get the money to land in the bank, move on. That worked fine until our first serious conversation with a local accountant, who asked a question I wasn't ready for — "can you send me the itemized settlement detail behind these deposits, not just the total?" That question is really what this article is about.

To be clear about scope: SMARTPAY is a licensed payment gateway, not an accounting firm, and nothing here is tax advice. What I want to walk through is the practical, structural side of the problem — what kind of transaction data a payment gateway can actually hand a merchant, why that data matters to the bookkeeping and BIR (Bureau of Internal Revenue) reporting process, and where the line sits between "payment provider's job" and "your accountant's job." If you're a merchant or technical lead trying to figure out how your payment stack should feed your finance stack, this is written from that seat.

Why Payment Data Matters Beyond the Checkout Page

Every transaction that moves through a gateway leaves a trail: an authorization event, a capture, a settlement batch, sometimes a refund or a dispute, and a fee deduction somewhere in between. Most merchants only look at the last step of that trail — the net amount that shows up in the bank account — and treat everything upstream as the gateway's internal business.

That's a mistake once you start thinking about bookkeeping. Your accountant doesn't book "money that appeared in the bank." They book revenue, they book the fees as a separate expense line, they reconcile refunds against the original sale, and they need all of that broken out by transaction, not collapsed into one deposit figure. If the only record you keep is your bank statement, you've thrown away the detail that makes any of that possible.

What a Settlement Report Actually Contains

A settlement report is the summary-level document that explains a batch payout: which settlement cycle it covers, the gross amount collected across the channels in that batch, the fees deducted, and the net amount actually disbursed to your account. It typically groups activity by settlement date and by payment channel — GCash, QRPH, Maya, card, or whichever mix you've enabled — so you can see where the volume is coming from.

This is useful, but it's a summary. It tells your accountant "this much came in, this much was deducted, this much was paid out," without telling them which specific orders that money came from. For a small operation that might be enough. For anyone trying to match revenue to actual sales — which is exactly what a clean set of books requires — you need one level deeper.

One level deeper than the settlement statement is the transaction-level export, which lists every individual payment event: timestamp, order reference, payment channel, gross amount, fee charged, net amount, and status (successful, refunded, charged back, failed). This is the file your accountant actually wants, because it lets them tie each line in your sales ledger back to a specific payment record, rather than working backward from a lump sum.

In my experience, the moment you can hand your bookkeeper a transaction-level export instead of a settlement summary, the monthly closing conversation gets noticeably shorter. Instead of "why doesn't this deposit match our order total," it becomes a straightforward row-by-row match. We built our own internal transaction data reporting workflow around exactly this export, pulling it on a fixed schedule rather than requesting it ad hoc.

How These Records Flow Into Your Bookkeeping

The general shape of the workflow, at least in our setup, looks like this: export transaction-level data from the merchant dashboard or API on a regular cadence, import it into whatever accounting system or spreadsheet the bookkeeper uses, and reconcile it against the sales ledger from your storefront or ERP. Any gap — a sale with no matching payment record, or a payment with no matching order — gets flagged before it becomes a closing-period headache instead of after.

This reconciliation step is where most of the actual work happens, and it's worth treating as its own discipline rather than a side task. We follow a structured payment reconciliation process that runs independently of the monthly close, specifically so discrepancies surface while they're still easy to trace back to a single order instead of buried in a quarter's worth of transactions.

Once reconciled, the data a bookkeeper actually enters into the books usually separates into a few buckets: gross sales revenue, processing fees as a deductible expense, refunds and reversals netted against the original sale, and any currency conversion detail if you're settling in more than one currency. None of that requires any judgment call about tax treatment — it's just making sure the numbers are complete and traceable before the accountant applies their own expertise to them.

Where Payment Records Intersect with BIR Reporting

This is the part I want to be careful about, because it's exactly where a payment company should stop talking and an accountant should start. Philippine businesses have periodic reporting obligations to the BIR, and the revenue figures in those filings ultimately trace back to actual sales activity — which, for an e-commerce merchant, means payment transaction records.

What I can say with confidence, because it's purely structural: your accountant will need itemized settlement and transaction records to support whatever figures go into a filing, and the cleaner and more complete that export is, the less reconstruction work they have to do. What I'm not going to do is tell you which specific filing applies to your business, how often it's due, or what rate applies to your revenue — that depends on your registration type, your business structure, and details only a licensed accountant or tax practitioner should assess. If you take one thing from this section, it's this: treat your payment data as an input to your accountant's process, not as a substitute for their judgment.

SMARTPAY operates in the Philippines under BSP OPS/EMI licensing, which governs our role as a regulated payment operator and electronic money issuer — it does not make us a tax advisory service. Our responsibility is to give you accurate, exportable records of what moved through our rails; interpreting what those records mean for your tax filings is squarely your accountant's role.

If you want the fuller picture of what that licensing actually covers, we've written separately about the BSP EMI license framework and how it differs from operating as an unlicensed intermediary.

Report Types We Can Export, and What Each One Is Actually For

Different stages of the bookkeeping process call for different levels of detail. Here's how the exports typically break down and who ends up using each one:

Report Type	What It Contains	Who Uses It and For What
Settlement Statement	Batch-level summary per settlement cycle: gross collected, fees deducted, net payout, grouped by channel	Finance team confirming deposits match expected payout totals
Transaction-Level Export	Every individual payment event with order reference, amount, fee, status, and timestamp	Bookkeeper matching each sale to its payment record during reconciliation
Fee Breakdown Report	Processing fees itemized separately from gross transaction amounts	Accountant booking fees as a distinct operating expense line
Refund and Chargeback Log	Reversed or disputed transactions with original order linkage	Bookkeeper netting refunds against the original sale instead of treating them as new entries
Payout History	Chronological record of disbursements to your bank account	Cross-checking against bank statements as an independent audit trail

Pulling Settlement Data Programmatically

If your finance workflow runs on a schedule — say, exporting data on a fixed day each month ahead of the bookkeeper's cycle — it's usually worth automating the export rather than logging into the merchant dashboard manually each time. A typical settlement export call looks something like this:

curl -X GET "https://api.paysmartph.com/v1/reports/settlement?date_from=2026-09-01&date_to=2026-09-30&format=csv" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Accept: application/json"

A transaction-level export follows the same pattern, just scoped to individual payment records rather than settlement batches:

curl -X GET "https://api.paysmartph.com/v1/reports/transactions?date_from=2026-09-01&date_to=2026-09-30&channel=all&status=all" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Accept: application/json"

A single record in the returned transaction set typically carries fields along these lines:

{
  "transaction_id": "TXN2026090417231",
  "order_reference": "ORD-88213",
  "channel": "gcash",
  "gross_amount": "0.00",
  "fee_amount": "0.00",
  "net_amount": "0.00",
  "status": "settled",
  "settlement_date": "2026-09-05",
  "currency": "PHP"
}

We pipe this straight into a staging table and let our reconciliation script match order_reference against our own order management system before anything reaches the bookkeeper. It's a small amount of engineering effort up front that removes a lot of manual spreadsheet work every single month.

Dividing the Work: What We Provide vs. What Your Accountant Handles

It's worth drawing this line explicitly, because merchants sometimes expect a payment provider to hand them a tax-ready number, and that's not a reasonable expectation from any gateway, regulated or not.

What a payment gateway is positioned to provide: accurate settlement statements, transaction-level exports, fee breakdowns, refund and chargeback logs, and an API that lets you pull all of it on your own schedule rather than waiting on a support ticket. What it is not positioned to provide: an opinion on your tax treatment, a determination of which filings apply to your business, or guidance on rates and deadlines. Those are squarely the domain of a licensed accountant or bookkeeper, who can also factor in things a gateway has no visibility into — your other income sources, your registration status, and your overall business structure.

Because SMARTPAY operates under BSP OPS/EMI licensing rather than as an informal or unlicensed intermediary, the records we issue are generated from the same regulated settlement rails that process the funds — not reconstructed after the fact. That consistency is part of why we can commit to accurate exports without extending that commitment into tax interpretation.

A few practical habits make this whole pipeline easier to maintain, based on what's worked for us:

Pull exports on a fixed schedule rather than only when the bookkeeper asks — gaps are much easier to catch close to when they happen.
Keep a consistent order_reference convention between your storefront and your payment integration so reconciliation doesn't depend on manual lookups.
Store raw exports somewhere durable, separate from your accounting software, in case you need to re-run a reconciliation months later.
Be mindful of how transaction data is stored and who has access to it — payment records contain customer and order detail that falls under the general data handling obligations that apply to merchant systems in the Philippines, separate from the tax question entirely.
Loop your accountant in on what exports are available before the first filing deadline comes up, not after.

Frequently Asked Questions

Does SMARTPAY file taxes or submit anything to the BIR on my behalf?

No. We provide transaction and settlement records. Preparing and filing anything with the BIR is handled by you and your accountant or bookkeeper.

What's the difference between a settlement report and a transaction-level export?

A settlement report summarizes a batch payout — gross, fees, net, by cycle and channel. A transaction-level export breaks that same activity down to the individual payment event, which is what most bookkeepers actually need for reconciliation.

Can I export records for a custom date range instead of a fixed monthly report?

Yes, both the dashboard and the API support specifying a date range, so you can pull data aligned to your own accounting periods rather than being locked into calendar months.

What format do exports come in?

Settlement and transaction exports are available as CSV for spreadsheet work or JSON for programmatic use, depending on how your finance workflow is set up.

Do settlement reports separate out processing fees, or do I have to calculate that myself?

Fees are itemized separately from gross transaction amounts in both the settlement statement and the dedicated fee breakdown export, so your accountant can book them as a distinct expense line without back-calculating.

Should reconciliation happen monthly, or is it fine to wait until the accountant needs it?

We've found it far easier to reconcile on a running basis — weekly or monthly — rather than compressing a whole filing period's worth of transactions into one session right before a deadline. Discrepancies are much easier to trace when they're still recent.

Can my accountant get their own access to pull reports directly?

Many merchants set up a separate dashboard login with view and export permissions for their accountant or bookkeeper, so they can pull what they need without routing every request through the merchant's own team.

What should I do if a number in my bank statement doesn't match the settlement report?

Treat it as a reconciliation task first — check for timing differences between settlement date and bank posting date, and check for any refund or chargeback that may have landed in a different cycle. If it still doesn't resolve, that's a support conversation with your payment provider, not something to guess around in your books.

If you're setting up this kind of reporting pipeline for a Philippines e-commerce operation and want to talk through what exports are available or how the API side works, reach out directly: @LouisSMARTPAY or [email protected].