System integration is where BIR e-invoicing compliance moves from policy and process into technology. For covered Philippine taxpayers, connecting existing ERP systems, accounting software, and POS terminals to the BIR Electronic Invoicing/Receipting System is the longest-lead-time component of the compliance project — and the one most likely to cause deadline misses if planning begins too late.
This guide covers the technical requirements for BIR EIS integration under RMC 98-2026, explains the three primary integration approaches (pre-built connector, API development, and provider portal), walks through the specific considerations for ERP, accounting software, and POS integration, and provides a structured testing and validation checklist for ensuring your integration is production-ready before go-live.
Key Takeaways
- BIR EIS integration requires transmitting invoice data in JSON format via REST API to a BIR-accredited ESP gateway — the API endpoint, authentication credentials, and JSON schema are all provided by the accredited provider.
- The fastest and lowest-risk integration path for most businesses is a pre-built connector from an accredited provider for your specific ERP or accounting software version — these connectors are pre-tested and BIR-certified.
- POS integration requires additional design considerations for high-transaction-volume environments: offline buffering, retry logic, and throughput testing are mandatory for retail and F&B businesses.
- Sandbox testing is a mandatory phase that cannot be abbreviated — every invoice type your business issues must be validated in the sandbox before the system is approved for production use.
- EIS certification is the final technical gate before go-live — it confirms your specific system configuration produces BIR-compliant submissions and is issued by the BIR through your accredited provider’s process.
What Does EIS Integration Mean in Practice?
EIS integration means that when an invoice is created in your billing or accounting system, the invoice data is automatically formatted as a BIR-specified JSON payload and transmitted — via your accredited provider’s API gateway — to the BIR EIS in near real time. The EIS validates the submission, assigns an EIS reference number, and returns it to your system, where it is stored and printed on the invoice document provided to the buyer. The entire process — from invoice creation to EIS reference number receipt — happens automatically, typically within seconds.
ERP integration BIR EIS creates a technical bridge between your invoice-generating system (the source) and the BIR Electronic Invoicing System (EIS) (the destination). This integration typically uses the accredited provider’s API infrastructure. Businesses must ensure their ERP can output invoice data in a format that maps correctly to the applicable BIR JSON schema, that the integration module transmits data reliably, and that the system handles EIS responses, including successful submissions and errors, appropriately.
BIR Technical Requirements for EIS Integration
RMC 98-2026 defines the technical specifications that all EIS integrations must comply with. Understanding these requirements before selecting an integration approach ensures you choose a path that actually meets the standards.
1. JSON Data Format
All invoice data must be transmitted in JSON (JavaScript Object Notation) format following the BIR-prescribed schema. The schema specifies field names, data types, formats (date as ISO 8601 YYYY-MM-DD, amounts as decimal with two places), and validation rules. Field names are case-sensitive and must exactly match the schema specification. The BIR schema has been updated through technical bulletins since RMC 98-2026; confirm with your provider that their implementation reflects the current schema version.
2. REST API Over HTTPS
Submissions are typically made through REST API calls over HTTPS, with separate sandbox and production endpoints provided by the accredited service provider. Authentication may use API keys or OAuth tokens, depending on the provider’s implementation. TLS/SSL certificate validation should remain enabled to protect data transmission and verify server identity. Meeting BIR e-invoicing technical requirements involves implementing secure authentication, proper certificate handling, reliable API communication, and appropriate error handling in the integration.
3. Near-Real-Time Transmission
RMC 98-2026 requires that invoice data reach the EIS at the time the invoice is issued. The BIR recognizes that some transmission latency is technically unavoidable, but systematic batch processing (submitting invoices accumulated over a day at end-of-day) is inconsistent with the near-real-time requirement. Your integration architecture should ensure transmission occurs during or immediately after invoice generation.
4. Mandatory Data Fields
Every submission must include all mandatory data fields from the BIR schema: seller TIN and registered name, invoice number and date, invoice type, buyer TIN and name (for VAT invoices), line item details, VAT amounts by rate, and invoice totals. Submissions missing any mandatory field are rejected. Implement field validation in your system before transmission to catch missing fields before they cause rejections.
Three Integration Approaches: Which Is Right for You?
1. Pre-Built Connector (Fastest Path)
A pre-built connector is a certified integration module developed by either the ERP/accounting software vendor or the accredited ESP, specifically for a named software platform and version. Connectors are available for major platforms: SAP S/4HANA, SAP Business One, Oracle EBS, Microsoft Dynamics 365 Business Central, Odoo, Quickbooks Online, Xero, and several Philippine-specific ERP platforms. A pre-built connector installs in your system, is configured with your provider credentials, and handles all JSON formatting, API transmission, and response handling automatically. Implementation time is one to three weeks rather than months.
2. API Integration (Most Flexible)
For businesses using custom ERP systems, bespoke billing software, or ERP versions without a pre-built connector, API integration involves developing a custom module that reads invoice data and submits it to the provider’s API. A development team or technology partner builds the integration using the provider’s API documentation and the applicable BIR JSON schema specifications. Depending on system complexity, development may take four to twelve weeks, followed by testing and validation. This approach is suitable when no pre-built connector exists for your platform. Review the BIR E-Invoicing Deadline to plan your implementation timeline.
3. Provider Portal Entry (For Very Low Volume)
Some accredited providers offer a web portal through which invoice data can be entered manually and submitted to the EIS. This approach involves no system integration — billing staff enter invoice details into the portal, which formats and submits the data to the EIS. This is appropriate only for businesses issuing very few invoices per month (fewer than 20–30). Any business with moderate invoice volume will find manual portal entry operationally unworkable and should use a connected integration approach.
ERP Integration: Key Technical Considerations
ERP integration connects the most complete and authoritative transaction data in your organization to the EIS. Major ERP platforms have multiple modules that generate invoices — accounts receivable, sales and distribution, project systems, service management — and the integration must cover all modules that generate customer invoices, not just the primary one.
1. Module Coverage Assessment
Map all ERP modules that generate customer invoices. In a complex ERP environment, it is common for one module to be connected to the EIS while other invoice-generating modules are overlooked. An integration audit at the design stage — listing every invoice-generating process and confirming EIS connectivity for each — prevents compliance gaps.
2. Master Data Quality
ERP customer master records must contain complete TIN data for all business customers. Run a TIN completeness audit before integration testing begins. Customer records without TINs cause EIS submission failures for every invoice to that customer. Bulk TIN verification services can cross-check existing customer TINs against BIR records.
3. Invoice Number Uniqueness
ERPs often use internal document numbers that may not conform to BIR invoice series conventions. Map your ERP’s internal invoice numbering to the BIR-registered invoice series. Ensure the mapping produces unique, sequential numbers that align with the series registered on your PTI.
POS Integration: High-Volume and Downtime Considerations
POS integration presents challenges not present in ERP integration: high transaction throughput, customer-facing checkout speed requirements, and the reality that POS terminals operate in environments where network connectivity may be intermittent.
1. Offline Buffering Architecture
Every POS integration must implement offline buffering—the ability to store transactions locally when EIS connectivity is unavailable and transmit them when connectivity is restored, according to applicable requirements. The buffer should be durable, have a defined capacity, and trigger alerts when it exceeds a set threshold. Lost transactions during outages can create compliance gaps. Italy Advintek supports businesses with e-invoicing integration and automated invoice processing solutions designed to streamline digital workflows and support applicable electronic invoicing requirements.
2. Transaction Throughput Testing
Load-test the POS integration at your peak transaction rate — the number of transactions per minute during your busiest period. Confirm that EIS submission latency does not create a queue backlog that affects checkout times. If throughput is insufficient, work with your provider to optimize batch size, connection pooling, or local pre-formatting.
3. Receipt Format Updates
POS receipts must be updated to include the EIS reference number. This is a physical change — receipt template, receipt printer configuration, or display configuration. Test the updated receipt format in the sandbox environment with actual printed receipt samples before go-live.
Testing and Validation Before Go-Live
| Testing Stage | What to Test | Pass Criteria |
|---|---|---|
| Data field mapping | All invoice types produce correct JSON with all mandatory fields | Zero missing field errors in test submissions |
| Sandbox submission | Representative sample of each invoice type accepted by EIS sandbox | EIS reference numbers returned for all valid submissions |
| Error handling | Intentionally malformed submissions trigger correct error codes | System logs errors and alerts; no silent failures |
| Downtime simulation | Offline buffer stores transactions; batch resend on reconnection | All buffered transactions transmit successfully after reconnect |
| Throughput testing | Peak volume of transactions within time window | EIS submission latency under 5 seconds per invoice at peak |
| EIS certification | Provider submits certification package to BIR on your behalf | BIR EIS certification confirmation received |
Conclusion
Technical integration is the implementation core of BIR e-invoicing compliance. Choosing the right integration approach for your systems, completing rigorous testing, and passing EIS certification before the December 31, 2026 deadline requires starting the project now. Each week of delay narrows the window for testing and resolving issues that are common in integration projects.
Nexright provides certified EIS integration services for ERP, accounting software, and POS systems. Our technical team has pre-built connectors for major Philippine business platforms and delivers API integration for custom systems. Contact us for a technical integration scoping session.
Frequently Asked Questions
1. How do I know if my ERP version has a pre-built connector available?
Contact your ERP vendor’s Philippines support team and your shortlisted accredited providers directly. Providers typically maintain a list of certified integrations on their websites or can confirm connector availability for your specific ERP version by email. Also check the BIR website for any published list of certified EIS integration solutions. When in doubt, ask your provider: “Do you have a certified connector for [ERP name] version [X.X]?”
2. Can I use the same EIS integration for both my sales invoices and my official receipts?
Yes. A single EIS integration can handle all invoice and receipt types your business issues: sales invoices for goods, official receipts for services, credit notes, debit notes, and cancellations. The transaction type code in the JSON payload distinguishes each type. Configure your integration to correctly map each document type from your source system to the corresponding BIR transaction type code.
3. How long does EIS certification take?
EIS certification, conducted through your accredited provider, typically takes one to three weeks from the time you complete sandbox testing. The provider compiles a certification package (test submission logs, data mapping documentation, system description) and submits it to the BIR on your behalf. Allocate at least four weeks before your intended go-live date for the certification process.
4. What should I do if my provider’s API is down and I cannot issue invoices?
If the provider’s API is unavailable and you have no buffering, you are in a downtime situation. Issue manual invoices using the BIR-approved downtime procedure, ensuring all manual invoices include all mandatory data fields and are logged for retroactive EIS transmission when the provider’s API is restored. Your service contract with the provider should include SLA commitments for API availability — review these before signing, and understand the provider’s escalation path for outages.
5. Can I have my IT team build the integration in-house without using a provider’s SDK?
Yes, but building a fully custom integration from scratch against the BIR EIS directly is not typically an option — you still need to transmit through an accredited provider’s gateway. Your IT team can build a custom integration against the provider’s API using their API documentation. This is the API integration approach described above. Most providers publish developer documentation and offer technical onboarding support for customer development teams.
6. What happens if I change providers after going live?
Changing providers after go-live requires: (1) applying for an updated PTI naming the new provider; (2) configuring and testing the new provider’s integration in sandbox; (3) completing EIS certification with the new provider; (4) switching production traffic to the new provider after go-live approval; and (5) maintaining records from the previous provider for the full retention period. Plan for a minimum of eight to twelve weeks to complete a provider change cleanly — do not cut over until the new integration is fully tested and certified.
7. If my integration rejects an invoice before EIS transmission, what do I tell the customer?
A pre-transmission rejection means the invoice data has a problem that prevents submission — typically a missing mandatory field (often a buyer TIN) or a data format error. Inform the customer that the invoice requires a data correction before it can be issued. Request the missing information (such as their TIN or correct registered address). Once corrected, reissue the invoice through the system. Do not provide the customer with a draft invoice that has not been EIS-validated — this creates ambiguity about whether a valid invoice has been issued.
Source by:
Image by Magnific
