Built for the BIR: Philippine Statutory Compliance, Automated

Ask most ERP vendors about Philippine tax compliance and the conversation quickly turns into a quote. Localization is the upsell: a separate module, a partner implementation, a yearly maintenance fee to keep the forms current as the Bureau of Internal Revenue (BIR) revises them. The base product handles "tax" in the abstract; the part that actually files in Manila is someone else's problem.

LedgerQ takes the opposite stance. Philippine statutory compliance is native — built into the platform, not strapped to the side of it. The same engine that records your invoices is the one that produces the BIR Form 2550Q VAT return, computes your Expanded Withholding Tax (EWT), assembles the RELIEF Summary Lists, and prepares the electronic payloads you submit through eFPS and the Electronic Invoicing System (EIS). There's no localization tier to buy. The books and the statutory forms are the same source of truth.

In summary: LedgerQ generates BIR outputs directly from your posted ledger — the quarterly VAT return (Form 2550Q), Form 2307 withholding certificates, RELIEF SLS/SLP DAT files, the BIR books of accounts, Alphalist attachments, and EIS e-invoice payloads. Because the forms read from the same GL that records your invoices, returns reconcile to your books by construction. LedgerQ is BIR CAS-ready; it is not itself BIR-accredited, and you still file through eFPS/eBIRForms.

How does LedgerQ generate BIR forms straight from the ledger?

The compliance work most teams dread is the month-end (and quarter-end) scramble: exporting transactions, re-keying them into a template, reconciling the template back to the general ledger, and hoping nothing slipped. LedgerQ removes that round-trip. Statutory output is generated directly from posted transactions:

• BIR Form 2550Q — the quarterly VAT return is footed from your actual output and input tax per rate, not a manually maintained worksheet, and it carries prior-period excess input VAT forward. (The monthly 2550M was discontinued in 2023; the BIR now expects the quarterly 2550Q, which is what LedgerQ produces.)
• RELIEF Summary Lists (SLS/SLP) — the Summary List of Sales and Summary List of Purchases are rendered in the BIR's .DAT format, drawn only from GL-posted invoices so they tie out to the 2550Q and the Sales Journal.
• Form 2307 certificates — per-vendor, per-quarter withholding certificates built from the EWT actually withheld on posted transactions.
• eFPS / EIS payloads — LedgerQ produces the electronic attachment files and maps each invoice to the BIR EIS payload, so transmission is a continuation of your bookkeeping rather than a separate data-entry exercise.

Because the forms read straight from the ledger, the numbers on your return match the numbers in your books by construction. Reconciliation stops being a manual ritual. If you want the field-by-field mechanics of the return itself, see our guide on how to file BIR Form 2550, the RELIEF SLSP DAT walkthrough, and the Alphalist preparation guide.

A worked example: how a VAT 2550Q comes together

Numbers make it concrete. Suppose, in a quarter, your business records ₱500,000 in vatable sales and ₱200,000 in vatable purchases (these are illustrative figures, not real data). At the standard 12% VAT rate:

• Output VAT (tax you collected on sales): ₱500,000 × 12% = ₱60,000.
• Input VAT (tax you paid on purchases): ₱200,000 × 12% = ₱24,000.
• Net VAT payable: ₱60,000 − ₱24,000 = ₱36,000.

In a spreadsheet world, you'd export sales and purchases, sum the VAT columns by hand, subtract, and pray the total matches the GL control accounts. In LedgerQ, every one of those invoices already posted its output or input VAT to the ledger when it was recorded — so the 2550Q simply foots those posted amounts. If you carried excess input VAT from the prior quarter, it's applied as a credit against the ₱36,000. And because only posted invoices flow through, the Summary Lists you file alongside the return reconcile to that same ₱60,000 / ₱24,000 automatically. There is no separate tax ledger to keep in sync.

How does LedgerQ compute Expanded Withholding Tax?

EWT is where a lot of generic "tax modules" quietly fall short. The Philippine regime isn't a single rate — it's a matrix of ATC (Alphanumeric Tax Code) values, each mapping to a specific income-payment type and its own withholding rate. Professional fees, rentals, and payments to contractors each carry a different ATC, and an individual payee is coded differently from a corporate one. Because the rate is baked into the code, using the wrong ATC effectively reports the wrong tax.

LedgerQ handles this the way the BIR actually defines it — at the moment the transaction is recorded, not reverse-engineered at filing time:

• ATC-coded withholding. Each withholding line carries its correct Alphanumeric Tax Code, so the remittance reports and Form 2307 certificates map cleanly to what the BIR expects.
• Withhold at booking. When you record a vendor bill subject to EWT, LedgerQ applies the rate the ATC implies, pays the vendor the net, and books the withheld portion to a withholding-tax-payable account — all in one posting.
• Flows through to filing. The captured EWT rolls up into the QAP (for the 1601-EQ), the MAP (for 0619-E), and the year-end Alphalist of Payees, so the quarterly and annual figures reconcile to what you remitted.

We deliberately don't reprint the ATC rate table here — the BIR revises it, and a stale rate is worse than no rate. LedgerQ carries the codes through from booking to filing; always confirm the current ATC and rate against the BIR's published table, and see the Alphalist guide for how the year-end list is assembled. The point is that withholding is computed as the transaction is recorded, with the ATC attached, instead of being pieced together at deadline.

What happens when a transaction isn't in pesos?

Here's the subtlety that breaks naïve localizations: businesses don't transact only in their functional currency. You invoice a customer in USD, receive a bill in SGD, and still have to file a peso-denominated VAT return. If the foreign amounts hit the statutory forms untranslated, the VAT base and the totals are wrong — and a wrong VAT base is exactly the kind of error the BIR notices.

LedgerQ FX-translates foreign-currency documents into the functional currency before they reach the statutory forms. A USD sales invoice is recorded with both its original USD amount and its peso equivalent at the transaction-date rate; it's the peso figure that foots into your 2550Q output VAT. So the ₱ total on your return reflects the properly translated base, not the raw foreign amount. A bolted-on localization that only sees peso transactions can't make this guarantee; a compliance layer that lives inside the ledger can.

What does EIS e-invoicing mean for your 2026 timeline?

Layered on top of the returns is e-invoicing. The BIR's Electronic Invoicing/Receipting System (EIS) has a mandatory-compliance deadline of 31 December 2026 (per RR 26-2025) for its first covered phase — large taxpayers, e-commerce sellers (excluding micro taxpayers), and businesses already running a Computerized Accounting System (CAS).

LedgerQ already maps each invoice to the BIR EIS payload, signs it under your tenant's key, and can transmit to the EIS API with acknowledgement tracking — plus a manual-portal mode for tenants who upload themselves. One nuance vendors blur: the EIS Certification and Permit to Transmit are things your business applies for, not the software vendor. Choose a tool that can transmit; you still register your system. Our EIS e-invoicing guide walks through the certification path, and the BIR CAS software guide covers what "CAS-ready" versus "accredited" actually means.

What does "native" compliance get you that a bolt-on doesn't?

The difference between "supports the Philippines" and "built for the BIR" shows up in the small things. It's the ₱ amounts that already reconcile because the form reads from the ledger. It's the withholding that carried its ATC from booking to Form 2307 without anyone re-tagging it. It's the foreign invoice that translated itself before it touched the VAT base. It's the EIS payload that was ready because the data never left the system.

When localization is an add-on, compliance is a project you re-run every period — and a line item you keep paying for. When it's native, compliance is a property of the system that holds as the business grows more complex: more currencies, more counterparties, more transactions. All of this reads straight into your financial reports, so the same posted ledger that files your BIR forms also produces your board pack. LedgerQ is built so that being correct for the BIR isn't extra work you bolt on — it's just how the books work. (To be precise about status: LedgerQ is CAS-ready and produces the required BIR outputs; it is not itself BIR-accredited, so you still file through eFPS/eBIRForms and register your own system.)

Frequently asked questions

Does LedgerQ file my BIR returns for me? No — and no software legitimately does. LedgerQ generates the outputs (2550Q data, RELIEF SLS/SLP DAT files, Form 2307, Alphalist and eFPS attachments, EIS payloads) directly from your posted ledger, so the numbers are your actual books with no re-keying. You still submit through eFPS, eBIRForms, or the EIS portal, and your business registers its own system with the BIR.

Is LedgerQ BIR-accredited? LedgerQ is BIR CAS-ready — it produces the CAS outputs and can transmit to EIS — but it has not obtained its own formal BIR Acknowledgement Certificate. "CAS-ready" and "accredited" are different things; if you need an already-accredited system on day one, factor that in.

Which VAT form does LedgerQ produce — 2550M or 2550Q? The quarterly 2550Q. The monthly 2550M was discontinued in 2023, so the quarterly return is the one the BIR now expects, and it's what LedgerQ foots from your posted output and input VAT.

Why does the withholding tax reconcile automatically? Because LedgerQ captures the ATC and the withheld amount at the moment you record each payment, rather than reconstructing them at year-end. That single captured figure flows through the quarterly QAP/MAP and the annual Alphalist, so your remittances and your year-end list tie out instead of contradicting each other.

How does LedgerQ keep a foreign-currency invoice from distorting my VAT return? It stores every foreign document with both its original amount and its peso equivalent at the transaction-date rate, and the statutory forms read the peso figure. So a USD or SGD invoice foots into your 2550Q at its properly translated base, not the raw foreign number — the VAT base stays correct even when the money isn't in pesos.