Philippines e-invoicing is the legal requirement to issue invoices in a structured digital format and send that data to the Bureau of Internal Revenue through its Electronic Invoicing System (EIS). It is not a PDF. It is not a scan. This Philippines e-invoicing FAQ answers the questions I get from finance teams almost every week, based on RR 11-2025 and RR 26-2025.
I have grouped the questions the way people actually ask them. Start with the basics. Skip to penalties or ERP integration if that is what is keeping you up at night.
It is the mandated process of generating a structured invoice and transmitting the data to the BIR via EIS within three calendar days. The invoice must be machine-readable JSON, digitally signed, and sent by API.
Here is the part people miss. Two things happen at once. You issue the invoice to your buyer through your normal channel. Your system also reports that same invoice to the BIR. Miss either half and you are non-compliant.
EIS stands for Electronic Invoicing System. It is the BIR's central platform that receives, processes, and stores the invoice and sales data you transmit.
The system was built with support from the Korean government and borrows heavily from South Korea's e-tax model. That heritage shows up in the API design, which matters once your developers start reading the spec.
EIS is the platform. ESRS, the Electronic Sales Reporting System, is the obligation to transmit your sales data to that platform without manual entry, in a structured format like JSON.
You need both. Generate the e-invoice, then report it. One without the other does not count.
The foundation is the TRAIN Law (RA 10963, 2018), which introduced Sections 237 and 237-A into the Tax Code. The CREATE MORE Act (RA 12066, 2024) then cleared up years of ambiguity.
The working rulebook today is RR 11-2025, effective 14 March 2025. RR 26-2025 pushed the Phase 1 deadline to 31 December 2026.
Sales invoices, service billings, credit notes, and debit notes. Under the EoPT Act, the old Official Receipt for services has been folded into the invoice, so service billing is now the principal services document.
One thing to flag early. A credit note or debit note must reference the original invoice's unique ID. Orphan notes get rejected.
This is where most of the confusion sits. The bir esi faq queries I see are almost always someone trying to work out if they are actually in scope.
Phase 1 under RR 11-2025 as amended covers four groups: e-commerce and internet businesses, taxpayers under the Large Taxpayers Service, large taxpayers under the EoPT Act, and users of CAS, CBA, or invoicing software.
That last category is the sneaky one. If you generate invoices through accounting software rather than by hand, you are probably in.
Micro-taxpayers are exempt for now, unless they already use an electronic invoicing system. Small is not the same as micro, so check your actual BIR classification before assuming you are safe.
I have watched a business with a modest turnover discover it was in scope purely because it ran invoicing software. Do not guess this one.
No. Exporters sit under a later phase that only starts once the BIR confirms its systems can handle the data. A separate Revenue Regulation will set that date.
Even zero-rated export sales will eventually need an e-invoice. Use the runway now, because Phase 2 will not come with a generous grace period.
Yes. If the head office is covered, every branch must issue e-invoices and comply with ESRS too. Each branch has its own configuration.
This is the single most common thing that catches companies out. They sort the head office, call it done, then find twenty branches still uncovered. A branch here means any location with its own four-digit branch code in the TIN, like 123-456-789-0001.
No. B2B, B2C, B2G, or export, a covered seller issues an e-invoice every time. What changes is the content of the JSON, not whether you send it.
For B2B the buyer TIN is mandatory. For B2C, buyer details can be generic under BIR guidelines.
The buyer need not take any action to receive the e-invoice. A covered seller transmits every transaction to the BIR automatically in the Philippines.
31 December 2026 for Phase 1 taxpayers. That is your go-live date, not your start date.
RR 26-2025 moved the original 14 March 2026 deadline to give taxpayers time to reconfigure systems and finish EIS certification. It was a practical call.
Worth remembering, this is the second time the timeline has slipped. The 2023 TRAIN target never landed either. That history breeds complacency, and complacency is expensive now that the penalty provisions are real.
Enforcement begins for non-compliant Phase 1 taxpayers. Phase 2, which brings in exporters, POS users, incentivised enterprises, and eventually B2C, gets triggered separately once the BIR confirms readiness.
Plan backwards from the deadline. Certification and testing usually eat four to eight weeks, sometimes more.
You have three calendar days from the transmission date to send the e-invoice. For B2C, the transaction is typically recognised upon payment. For B2B, the transaction date could be the date of delivery or handover of goods and not payment.
If you are searching for a BIR e-invoicing guide on the technical side, this is the section to bookmark.
Structured JSON is the standard in practice, carrying a JWS digital signature that authenticates the document and stops it being altered. XML is referenced as an alternative, but JSON is what everyone builds against.
A PDF, Word file, or scan is not an e-invoice. The signed JSON is the source of truth. The pretty human copy is just a picture of it.
Roughly twenty core fields under the current EIS schema, covering seller and buyer identifiers, transaction detail, the tax breakdown, and the JWS signature. Here is the working list.
| Field group | What it captures |
| Document info | Unique number, issue date and time, document type code |
| Seller | 9-digit TIN plus 4-digit branch code, legal name, registered address |
| Buyer | TIN, name, address (required for B2B and large B2C) |
| Line items | Description, quantity, unit of measure, unit price, line totals |
| Discounts | Four separate types: Senior Citizen, PWD, Regular, Special |
| Withholding | Four buckets: Income Tax Withheld, CWT, Business Tax, BPT |
| Tax | VAT at 12%, zero-rated and exempt subtotals, VAT amount |
| Currency | Transaction currency plus PHP equivalent on every invoice |
| Signature | JWS digital signature |
Two of these quietly break most ERP setups. The four discount types and four withholding buckets are each separate fields. Most systems store one lump discount and one tax figure. Fixing that mapping is real work, not a checkbox.
Within three calendar days of the transaction date. The BIR frames it as real-time or near real-time, with three days as the hard ceiling.
Each invoice is capped at 1,000 line items, and an API call can carry up to 100 invoices. If you routinely issue very large invoices, you will need to split them.
The PTT is the BIR's formal go-ahead to send live invoice data to EIS. No PTT, no production transmission.
To get it you first complete EIS certification, pass sandbox testing, and then wait for approval. The PTT comes with four registered IP slots. The certification queue gets congested near deadlines, so start early.
The AC is the BIR licence for your invoicing software, filed at branch level. Without an active AC, EIS rejects your payloads.
It is a nine-document pack, and the hardest item is the Annex B compliance matrix, a line-by-line mapping of every BIR rule to a feature in your system. Allow four to six weeks. This is what BIR examines during post-evaluation.
Each invoice is signed using JWS with RS256, which is RSA plus SHA-256. Your private key stays in your own KMS or HSM and never leaves your control.
The BIR rotates its public key. The latest rotation was dated 25 July 2025, so treat key rotation as a routine operational event, not a one-off. Miss a rotation and every transmission silently fails.
Here is the sequence for e-invoice registration in the Philippines as it stands today.
Budget six to ten weeks end to end. AC preparation runs three to four weeks, the AC itself is issued in about three working days, and certification plus PTT takes another two to four weeks. Start three months before go-live.
CAS registration gives you a Permit to Use covering your accounting records. EIS registration links your invoicing system to the BIR platform for transmission.
They are separate. A valid CAS permit does not mean EIS is sorted, and I have seen companies find that gap two weeks before go-live.
Section 264 covers failure to issue: a fine of PHP 1,000 to PHP 50,000 per offence plus two to four years imprisonment. Section 264-A covers late or failed transmission: PHP 10,000 or 1/10 of 1% of annual net income per day, whichever is higher.
Run the maths. A company with PHP 100 million in annual net income faces daily exposure of PHP 100,000. Three months of drift is roughly PHP 9 million, and past 180 days of violations in a year, closure is on the table.
Yes. Responsible officers, not just the company, can face fines and imprisonment under the Tax Code. This is why the authorised signatory on the AC Sworn Statement is not a formality.
Yes. Under CREATE MORE, you can claim an extra deduction for the cost of setting up your reporting system: 100% for micro and small taxpayers, 50% for medium and large.
This applies whether you are mandated or you opt in voluntarily. For a mid-sized business, it is a genuine offset worth putting in the investment case.
Yes, and for anyone with real volume, ERP integration with BIR EIS is not really optional. Meeting the three-day window across every branch by hand does not hold up.
Your ERP must generate compliant JSON, apply the JWS signature, transmit to the BIR endpoint, and handle the accept or reject response. Most of the effort is in connectivity, schema mapping, and error handling, not in printing the invoice.
No. Oracle, SAP, and Microsoft Dynamics were not built for BIR EIS natively. You need a certified localisation module, a middleware connector, or custom development.
A configuration built for another market does not transfer. The Philippines schema is its own thing, so treat it as a separate jurisdictional build with its own mapping, credentials, and transmission logic.
Your ERP produces the invoice data. A Sales Data Transmission System converts it to BIR JSON, signs it, delivers it to the buyer, and sends the same invoice to EIS within three days.
The BIR then validates format, signature, TIN, serial range, and AC status. Accepted invoices come back with a unique ID that gets stamped on your record. Rejected ones drop into an error queue for your finance team to fix and retransmit under the same invoice ID.
A single outage inside the three-day window can push hundreds of invoices past the deadline, and each one is a separate penalty. Private key loss or expiry silently fails every transmission.
The other quiet killer is the edit button, because there isn't one. Wrong invoice, wrong serial, you correct it with a credit note or a cancel and re-issue. Serial gaps, backdating, and duplicates all trigger automatic audit flags in an electronic invoicing system Philippines regulators can watch in real time.
No, not in most cases. When the BIR rejects a transmission, it is rejecting the format or validation of the data sent to the BIR, not the commercial invoice you gave your customer. You correct the JSON and re-transmit to the BIR under the same invoice reference. The buyer copy is untouched.
There is one exception worth knowing. If the underlying invoice content was actually wrong, say the amount, the TIN, or the tax treatment, then the buyer copy needs correcting too. That is done through a credit or debit note referencing the original invoice, not by silently editing the record. Format rejections stay between you and the BIR. Content errors reach the buyer.
Until you obtain your PTT, yes, up to 31 December 2026. Once you go live on EIS, manual invoicing for covered transactions stops.
The BIR has not signalled a parallel-run grace period after the deadline. Treat 31 December 2026 as a hard switch, not a soft advisory.
Starting too late, confusing CAS registration with EIS readiness, forgetting the branches, assuming the ERP does this natively, and testing only the happy path. I see these five on repeat.
The happy path one bites hardest. The BIR returns an accept or reject for every transmission, and systems tested only on clean data fail quietly in UAT and loudly in production. Build rejection handling in from day one.
e-Invoices must be stored in a retrievable digital format for 10 years. Store the full signed invoice, not just the unique ID (UIN) the BIR returns on acceptance. Storage can sit with you or be handled by your solution provider. ClearTax can store the transmitted invoices and their acknowledgements on your behalf, so the archival obligation does not become a separate project.