BIR e-invoicing in the Philippines means issuing invoices from a registered invoicing system, in a structured electronic format, delivered to the buyer electronically, with invoice data that can be extracted and transmitted to the Bureau of Internal Revenue for sales reporting. A PDF exported from ordinary software and emailed, or an invoice typed up in Word or Excel, is not one. RR No. 11-2025 defines the covered-taxpayer logic for electronic invoicing and the BIR electronic sales reporting model, and RR No. 26-2025 extends the compliance period for the first covered groups to December 31, 2026. RMC No. 98-2026, issued on September 22, 2026, confirms that date and sets the operating rules behind it.
The immediate RR No. 26-2025 groups are e-commerce or internet-transaction taxpayers classified as small, medium, or large taxpayers, taxpayers under the Large Taxpayers Service, large taxpayers under RA No. 11976 and RR No. 8-2024, and taxpayers using CAS, CBA with electronic invoicing accounting records, or other invoicing software. Micro taxpayers in the specified e-commerce or internet-transaction category are exempted from that mandatory requirement. Other groups, including exporters, registered business enterprises availing tax incentives, POS users, and taxpayers later named by the Commissioner, move under separate regulations once the BIR system is ready to store and process the required transmitted data.
Two BIR steps stand between a covered taxpayer and its first compliant e-invoice: a PTI Electronic Invoice (Permit to Issue) from its Revenue District Office or Large Taxpayer office, which must be approved before any e-invoice is issued, and EIS Certification, which must follow within six months of the PTI. Electronic sales reporting to the BIR is a separate duty that the BIR has not yet switched on. For now, the December 31, 2026 obligation is to issue e-invoices.
Who Is Covered and How the 2026 Deadline Works
The first scope question is not whether every Philippine business must switch at once. It is whether your entity falls within the BIR's covered-taxpayer logic under RR No. 11-2025 and the transitory provisions amended by RR No. 26-2025. The BIR's RR No. 26-2025 digest sets out the December 31, 2026 groups and the categories that come later through separate regulations, and the BIR's RMC No. 98-2026 restates the first group as its own coverage.
| Scope question | Taxpayer groups | Practical reading |
|---|---|---|
| Must comply with electronic invoice issuance by December 31, 2026 | E-commerce or internet-transaction taxpayers classified as small, medium, or large taxpayers; taxpayers under the Large Taxpayers Service; large taxpayers under RA No. 11976 and RR No. 8-2024; taxpayers using CAS, CBA with accounting records and electronic invoicing, or other invoicing software | Treat the deadline as the date e-invoices must already be issuing, which means the PTI must be approved before it. These groups need time for system configuration, the PTI application, and testing. |
| Exempted from the mandatory requirement in the e-commerce or internet-transaction category | Micro taxpayers | Do not assume exemption from every future e-invoicing development. Read this as the RR No. 26-2025 mandatory-scope caveat. A micro taxpayer can adopt e-invoicing voluntarily, but needs its own PTI Electronic Invoice from its Revenue District Office to do so. |
| Expected through later or separate regulations once the BIR system can store and process the transmitted data | Exporters, registered business enterprises availing tax incentives, POS users, and other taxpayers required by the Commissioner | Monitor later BIR issuances instead of treating the December 31, 2026 list as the final shape of the regime. |
Two rules in RMC No. 98-2026 widen what "covered" means in practice. Coverage applies to the taxpayer as a whole: the head office and every branch must issue e-invoices, whether or not the covered activity happens at that branch. And a later change of classification under the EOPT framework does not switch the duty off. A taxpayer reclassified downward, such as Small to Micro, keeps complying; one reclassified upward takes on its new category's obligations within a period the BIR sets, of no less than six months.
BIR EIS: Electronic Invoicing and Electronic Sales Reporting Are Separate Duties
Issuing electronic invoices (Section 237 of the Tax Code) and reporting sales data to the BIR (Section 237-A) are two obligations, and RMC No. 98-2026 calls them "separate and distinct." The December 31, 2026 deadline is for issuing. Covered taxpayers must comply with electronic sales reporting only once the BIR issues the implementing policies, guidelines, and procedures for it, and the Permit to Transmit (PTT) that lets a system send sales data to the BIR's EIS, its electronic invoicing and sales reporting system, applies only on the Commissioner's notice or directive. In the BIR's announcement of the circular, Commissioner Charlito Martin R. Mendoza said: "For now, taxpayers should focus on complying with the electronic invoicing rules. Electronic sales reporting will follow once the BIR issues the separate implementing policies and procedures for it."
Reporting still shapes the system requirements today. An e-invoice must be capable of having its data extracted, processed, and transmitted to the BIR, and EIS Certification tests that capability before any sales data is sent. For the reporting itself, the existing EIS rule in RR No. 8-2022 is the one to plan against: sales data transmitted in real time or near real time, and within three calendar days from the date of the transaction. That is the rule behind "transmission to the BIR within 3 days." For the taxpayers RMC No. 98-2026 covers, it applies only once the BIR activates reporting.
What RR No. 26-2025 Changed
RR No. 26-2025 amended the transitory provisions of RR No. 11-2025. Its main practical effect was to extend the compliance period for the first covered groups to December 31, 2026, because taxpayers needed operational time for system reconfiguration and transition to electronic invoicing. RMC No. 98-2026 then confirmed the date and set out how compliance works: the PTI, EIS Certification, branches, downtime, and corrections.
The later deadline is implementation runway, not permission to wait. For multinational groups and shared-service centers with the Philippines inside their invoicing footprint, the scope assessment belongs now: early mapping costs little compared with discovering in December that a billing, POS, or e-commerce invoicing process cannot issue e-invoices.
PTI Electronic Invoice and EIS Certification
RMC No. 98-2026 adds two BIR approvals to the rollout, in a fixed order.
| Step | What it is | Where | When | If missed |
|---|---|---|---|---|
| PTI Electronic Invoice (Permit to Issue) | The BIR's authority to issue e-invoices through a named, registered invoicing system | The Revenue District Office or Large Taxpayer office where the taxpayer is registered | Before the first e-invoice is generated or issued; the BIR evaluates within 20 working days of receiving complete documents | No e-invoice may be issued without it |
| EIS Certification | Online testing that the system can extract, process, and transmit sales data to the BIR's technical standards: five mandatory tests, or seven with API callback | The EIS Certification Portal at eis-cert.bir.gov.ph | Within six months of the PTI | Ground for revoking the PTI |
The PTI is not the Permit to Use (PTU) or Acknowledgement Certificate that a CAS already holds. Those authorize using the system; they do not authorize issuing e-invoices through it, so a taxpayer with a long-registered CAS still needs a PTI. Each PTI names the approved system and its coverage. The head office and each branch receive a PTI under the same PTI number, each naming its branch, while a taxpayer running different invoicing systems for different branches, offices, or business segments needs a separate PTI for each system. A new branch on an approved system needs a notice to the BIR, not a new PTI number. Any change to the approved system's identity, name, platform, or core details, including migrating to or adopting another system, needs a new or amended PTI.
The order of the steps sets the real deadline. A covered taxpayer must be issuing e-invoices by December 31, 2026, it cannot issue one before its PTI is approved, and the BIR's 20 working days start only once the application's documents are complete. An application filed in December, with the year-end holidays inside the window, may not be decided in time. File early enough for the evaluation, and any request for missing documents, to finish before the deadline. RMC No. 98-2026 refers to "prescribed documentary requirements" without listing them, so confirm the current list with your RDO or LT office before filing.
EIS Certification may follow go-live within the six months, but it tests the capability an e-invoice must already have: data that can be extracted and sent to the BIR. A system that cannot pass the tests puts the PTI itself at risk, so test well before the six months run out. The Permit to Transmit is a later, third step that waits for the BIR's reporting rules.
Why a PDF Invoice Is Not the Same as a BIR-Compliant Electronic Invoice
The most important distinction in this topic is the difference between a document and a data process. A PDF invoice, a scan, or an invoice sent by email may be perfectly usable for customer communication and internal filing, but that does not automatically make it a compliant electronic invoice for Philippine e-invoicing purposes. The BIR is focused on the system that produces the invoice and the data inside it.
That point is explicit in the rules. Under RMC No. 98-2026, an invoice is an electronic invoice only if it meets all three conditions:
- It is generated by a duly registered, approved, or accredited accounting or invoicing system, in a structured electronic format.
- It is generated and transmitted to the buyer in digital form: by email, online viewing, QR code, mobile app, web platform, or other electronic means.
- Its data is capable of being electronically extracted, processed, and transmitted to the BIR for sales reporting.
Invoices made manually in Microsoft Word, Excel, Google Docs, Google Sheets, or similar applications are not valid electronic invoices. And as BIR's RR No. 11-2025 digest explains, invoices generated from CAS, CBA, POS, or other invoicing software are not considered electronic invoices unless the system can transmit the required invoice data electronically to the BIR. RMC No. 98-2026 adds that such invoices, printed for the buyer, fall under the rules for non-electronic, system-generated invoices. That is the dividing line between "we issue invoices electronically" in the everyday business sense and "we meet the BIR's electronic invoicing requirements" in the compliance sense.
A useful way to explain the difference is:
- A PDF workflow creates a visual document that humans can read, email, print, or archive.
- A BIR-capable electronic invoicing workflow creates invoice data in a structured form from a system covered by a PTI, delivers it to the buyer electronically, and can hand that data to the BIR when reporting begins.
This is why ordinary digital maturity can create false confidence. A company might already generate invoices from its ERP, attach them to emails automatically, and store them in a document system. None of that answers the key compliance question on its own. If your team needs a broader foundation on how structured e-invoicing differs from sending a PDF invoice, that distinction becomes much clearer once you view the invoice as a regulated data record rather than a finished file.
The delivery channel is not the line either. Email is one permitted way to deliver an e-invoice, and an e-invoice from a PTI-covered system stays an e-invoice when it is printed for a buyer who asks, or in B2C sales where electronic delivery is impractical. A PDF exported from a system without that capability does not become one by being emailed.
How Invoice Content Rules Differ From Transmission and Reporting Duties
Teams often mix up two different compliance layers. The first layer is document content: what fields must appear on the invoice, how the transaction should be characterized, and when a business should issue an invoice rather than another type of document. The second layer is system behavior: how invoice data is generated, transmitted, reported, and retained within the BIR's electronic framework.
That distinction matters because a business can get the content layer mostly right while still falling short on the system layer. An invoice template may include the right commercial and tax details, yet the company may still lack the process needed to produce structured invoice data or to support the BIR-facing transmission and sales-reporting workflow. In other words, a compliant-looking invoice is not the same thing as a compliant invoicing process.
The BIR's data format keeps the two layers apart. The EIS prescribes JSON for transmitting sales data, and RMC No. 98-2026 says the JSON is not designed to change what an invoice shows: its fields come mainly from the minimum invoice information under Section 113 of the Tax Code and RR No. 7-2024, plus details most taxpayers already record, such as discounts and withholding taxes. A system that uses XML or another structured format internally may keep it, provided the sales data can be converted to the BIR's format and transmitted in it.
For readers working through local tax-document rules, it helps to keep those questions separate. If your immediate concern is document fields and the shift in invoice-versus-official-receipt treatment, the related guide on Philippines invoice field and invoice-versus-official-receipt rules after EOPT covers that layer. This article is about the additional obligations created when the BIR expects the invoice flow itself to be electronically reportable.
Project teams usually scope better when they divide the work this way:
- Content layer: invoice fields, document classification, customer-facing format, and tax-document logic.
- System layer: data extraction or generation rules, transmission capability, validation controls, exception handling, and reporting readiness.
Once those layers are separated, ownership becomes clearer. Tax and finance can define what the invoice needs to say, while ERP, POS, billing, and compliance teams can assess whether the transaction data can move through a BIR-capable electronic process.
What Finance, ERP, POS, and Billing Teams Need to Change
Most implementation work will happen below the surface of the invoice. Finance teams need to understand where invoice data originates, how it is transformed, which system becomes the source of record, and whether that source can support the reporting model required by the Philippines electronic invoicing regime. In many organizations, this means mapping data flows across ERP billing modules, e-commerce platforms, POS environments, export documentation, and local tax-reporting processes rather than looking at the invoice template alone.
Existing CAS, CBA, and POS setups deserve special attention. Approval, registration, or long-standing operational use does not automatically mean the system already satisfies the new electronic invoicing model, and a CAS's Permit to Use does not authorize e-invoicing without a PTI. The core review question is whether the platform can generate the necessary structured invoice data and support the required electronic reporting path to the BIR. Readers working through the software-governance side of that issue should also review CAS rules for invoicing software and BIR system approvals, because system approval history and e-invoicing capability are related but not identical questions.
The route matters too. RMC No. 98-2026 lets a taxpayer issue e-invoices from an in-house system, a commercially acquired one, or through an e-invoicing service provider (ESP). Under RMC No. 110-2026 of October 12, 2026, an ESP may not provide e-invoicing to taxpayers unless the BIR has accredited the specific solution and the provider holds a valid Electronic Invoicing Solutions Accreditation Certificate, which lasts five years with an annual compliance review. A taxpayer's PTI stays valid only as long as its provider's certificate does. A system developed in-house, or licensed software run on the taxpayer's own infrastructure, used only by one taxpayer and its branches stays under the CAS, POS, or other registration rules, while a system offered to a related party or franchisee counts as an ESP service. As BDB Law's advisory on the circular sets out, engaging an ESP does not relieve the taxpayer of its own duty to issue accurate invoices and report sales.
From an operating-control perspective, teams should expect to define more than just field mappings. They also need:
- Clear ownership for invoice-data creation
- Validation rules for missing or inconsistent transaction data
- A correction procedure that never edits an issued e-invoice: a decrease goes through a duly authorized credit note or memo and an increase through a new e-invoice, each referencing the original (the BIR will set sales-adjustment rules in a separate issuance)
- A downtime procedure: during a system outage, connectivity or power loss, cybersecurity incident, or force majeure, the taxpayer issues BIR-authorized manual invoices, so a covered taxpayer still needs them on hand, and on restoration replaces each one with an e-invoice bearing the manual invoice's reference number
- Traceability between source records, issued invoices, and the data that will be transmitted
- Retention procedures that preserve both the document and the supporting data history
These requirements affect both upstream and downstream workflows. Billing teams may need cleaner master data and tax logic. ERP teams may need new interfaces or export structures. POS owners may need to review whether transaction records can feed the required reporting format. Audit and finance teams may need better evidence trails for why an invoice was issued, corrected by a credit note or a new e-invoice, or replaced after downtime. Teams that capture inbound invoices for reconciliation or audit support should also confirm that downstream validation and storage processes reflect the same structured-data assumptions used in the outbound invoicing flow. The same logic applies to withholding documentation, where building the SAWT and QAP alphalists from 2307s received and issued depends on field-level data rather than on filed copies of the forms.
The BIR rules are not only about issuing invoices electronically. They are about building a controlled invoice-data process that can stand up to validation, reporting, and later review.
A Practical 2026 Readiness Checklist for Philippines E-Invoicing
If you need to turn the regulations into an internal work plan, start with a short readiness checklist rather than a broad transformation program.
- Confirm scope for the whole taxpayer. Check the legal entity against the covered groups under RR No. 11-2025, RR No. 26-2025, and RMC No. 98-2026, remembering that coverage takes in the head office and every branch.
- Inventory every invoicing system. List the ERP, billing, POS, e-commerce, and other systems that issue invoices, since each distinct system needs its own PTI.
- Choose the route. Decide between an in-house system, commercial software, and an ESP, and for an ESP confirm that the specific solution holds a valid Electronic Invoicing Solutions Accreditation Certificate under RMC No. 110-2026.
- Apply for the PTI early. File with your RDO or LT office with complete documents, early enough for the 20-working-day evaluation to finish before December 31, 2026.
- Issue e-invoices only under the PTI. Retire Word, Excel, and emailed-PDF invoicing for covered sales, and keep a way to print an e-invoice for buyers who ask.
- Pass EIS Certification. Run the five mandatory tests, or seven with API callback, on the EIS Certification Portal within six months of the PTI.
- Set the downtime and correction procedures. Keep BIR-authorized manual invoices for outages, with a replacement step afterwards, and route every correction through a credit note or a new e-invoice.
- Prepare for sales reporting without starting it. Map invoice data to the BIR's JSON format, design for transmission within three calendar days, and watch for the BIR's reporting rules and the Commissioner's PTT directive.
- Assign ownership. Name the teams responsible for tax interpretation, the PTI application, system change, testing, operations, and ongoing monitoring.
The deadline is not met by producing an invoice in digital form. It is met by having each invoicing system covered by a PTI and issuing from it by December 31, 2026, with EIS Certification to follow and reporting after that. Organizations still uncertain about scope should begin with fact-finding now: verify coverage, list the systems, find where PDF and spreadsheet habits hide a missing PTI or data capability, and file the PTI application well before December. Teams that do this early can treat the Philippines e-invoice requirements as a controlled implementation program instead of a late compliance scramble.