Technical integration between a business’s existing billing and accounting systems and the BIR Electronic Invoicing/Receipting System (EIS) is the core engineering challenge of Philippines e-invoicing compliance. For many covered taxpayers, the integration project — not the regulatory analysis — is the longest lead-time item in the compliance journey. Getting the integration right means your EIS submissions are accurate, timely, and consistent with your accounting records. Getting it wrong means rejected submissions, compliance gaps, and audit exposure.
This article provides a practical guide to BIR EIS integration, covering what integration actually means, the BIR’s technical requirements, how to connect ERP systems and POS systems to the EIS, how to test and validate your integration before going live, and what the post-go-live monitoring process looks like. Whether you are a business owner overseeing a compliance project or a finance manager coordinating with an IT team, this guide gives you the practical framework for a successful integration.
Key Takeaways
• EIS integration means your billing or accounting system transmits invoice data in BIR-prescribed JSON format to the EIS API via your accredited provider — no manual uploads or portal submissions are involved.
• BIR-prescribed data fields for every e-invoice include the taxpayer TIN, invoice number, invoice date, buyer TIN (for VAT invoices), item description, unit price, quantity, total, and applicable VAT amount.
• The three integration approaches are: pre-built connector (fastest, lowest cost), API integration (most flexible for custom systems), and manual provider portal entry (for very low volume businesses).
• ERP and POS integration projects typically take four to eight weeks — longer if custom development is required, shorter if a pre-built connector exists for your specific software version.
• Sandbox testing before go-live is not optional — it is the process by which you confirm that your system produces valid, BIR-accepted invoice submissions without data errors before any real transactions are involved.
What Is BIR EIS Integration?
BIR EIS integration refers to the technical connection between a taxpayer’s invoice-generating system (their ERP, accounting software, POS, or billing platform) and the BIR’s EIS API — via a BIR-accredited service provider’s gateway. When an invoice is generated in your system, the integration module automatically formats the invoice data into the BIR’s JSON specification, submits it to the provider’s API endpoint, waits for the provider to transmit it to the EIS, and receives the EIS reference number back. This reference number is then embedded in the invoice record in your system and printed on the invoice document provided to the buyer.
Integration is not optional — it is the mechanism by which e-invoicing compliance is achieved. A business that has an accredited provider contract and a PTI but has not completed the technical integration between its billing system and the EIS is not compliant, because no invoice data is being transmitted. Conversely, a business that has completed a solid integration typically finds that ongoing compliance is largely automatic — invoice data flows to the EIS without manual intervention, and the only ongoing management task is monitoring the transmission dashboard for errors.
BIR Technical Requirements for EIS Integration
RMC 98-2026 specifies the technical standards for EIS integration in detail. The data transmission format is JSON (JavaScript Object Notation). Data is submitted via REST API using HTTPS, with authentication credentials provided by the accredited provider. Every invoice submission must include a complete set of mandatory data fields — no optional fields can substitute for required ones, and submissions with missing required fields are rejected by the EIS without a reference number assignment.
1. Mandatory Invoice Data Fields
Every e-invoice submission must include the following data at minimum: the taxpayer’s TIN and registered business name, the invoice series number and date, a unique transaction identifier, the buyer’s TIN and registered name (for VAT invoices), the invoice line items (description, quantity, unit price), the total invoice amount before VAT, the applicable VAT amount (12% standard, 0% for zero-rated, or “Exempt” for VAT-exempt transactions), and the total invoice amount including VAT. Additional fields are required for specific transaction types — credit notes, cancellations, and cross-border transactions have supplementary field requirements.
2. API Connectivity and Authentication
The accredited provider supplies API credentials (typically an API key or OAuth token) that authenticate your system’s submissions. The API endpoint URLs are provided by the provider and are specific to the test (sandbox) and production environments. Test and production environments must be kept strictly separate — submitting test transactions to the production API, or live transactions to the sandbox, creates records in the wrong environment and requires correction.
3. Response Handling
A successful EIS submission returns an HTTP 200 response with a JSON body containing the EIS reference number and a validation timestamp. A failed submission returns an HTTP 4xx or 5xx response with an error code and description that identifies the specific validation failure. Your integration must implement logic to handle both success and failure responses: storing EIS reference numbers for successful submissions and logging error details for failed ones, with an alert mechanism for repeated failures.
How to Integrate ERP Systems With BIR EIS
ERP integration is the most complex integration scenario, but also the most impactful — an integrated ERP connects every invoice generated across the organization, across all modules (accounts receivable, order management, project billing) to the EIS in a single, uniform process.
1. Assess Pre-Built Connector Availability
Before any custom development begins, check whether your ERP vendor or your accredited provider has published a certified connector for your ERP version. Connectors are available for major platforms including SAP (various versions), Oracle EBS, Microsoft Dynamics 365, Odoo, and several local Philippine ERP platforms. A pre-built connector reduces integration time from months to weeks and carries the provider’s certification that the integration produces BIR-compliant submissions.
2. Map Invoice Data Fields to BIR Schema
Even with a pre-built connector, a data field mapping exercise is required to ensure that the data in your ERP’s invoice records aligns with BIR requirements. Common mapping issues include: ERP customer records that do not capture TINs (add a TIN field and populate it for all customers), product/service descriptions that are too abbreviated for BIR data fields (extend descriptions), and invoice series formats that do not match BIR numbering conventions. Complete this mapping and data cleanup before beginning integration testing.
3. Complete Sandbox Testing
Using the provider’s sandbox environment, submit a representative sample of each invoice type your business generates: standard VAT invoices, zero-rated invoices (if applicable), VAT-exempt invoices, credit notes, and cancellations. Test edge cases — invoices with many line items, invoices with mixed VAT rates, invoices for non-VAT registered buyers. Confirm that the sandbox returns valid EIS reference numbers for all correct submissions and meaningful error messages for intentionally incorrect submissions.
How to Connect POS Systems to BIR EIS
POS integration presents different challenges than ERP integration because POS systems typically operate in high-volume, real-time transactional environments where EIS latency can affect customer-facing checkout speed. The integration approach must account for these operational constraints.
1. Evaluate POS Vendor BIR Compliance
Many POS system vendors have developed or are developing BIR EIS compliance modules for their platforms. Contact your POS vendor to determine whether a BIR-compliant version or update is available for your specific model and software version. If your POS vendor has not developed a compliance solution, you may need to integrate through a middleware layer between the POS and the EIS.
2. Implement Offline Buffering
POS environments require offline buffering — the ability to store transactions locally during EIS unavailability and transmit them in batch when connectivity is restored. This is consistent with the BIR’s downtime procedure. Your POS integration should include a local buffer that stores unsubmitted transactions and a reconciliation process that confirms every buffered transaction has been successfully transmitted to the EIS.
3. Test Transaction Throughput
Load-test your POS EIS integration with a volume of transactions equivalent to your peak transaction period — Black Friday, peak lunch hour, the last week of the month. Confirm that the integration can process transactions at the required volume without creating a backlog that affects customer checkout times. If throughput is insufficient, work with your provider to optimize the submission architecture.
Accounting Software Integration and Pre-Go-Live Check
For businesses using cloud accounting software (Xero, Quickbooks, etc.), integration typically involves enabling a BIR EIS connector module provided by either the software vendor or an accredited ESP. These connectors are the simplest integration path — they are pre-built, tested, and typically activate within days. The primary pre-go-live checks are: confirming that all customer TINs are populated in the accounting system, verifying that invoice templates include all mandatory BIR data fields, and running a sandbox test with representative invoice types.
A final pre-go-live checklist should confirm: PTI approval received; EIS certification completed; production API credentials configured; test submissions successful in sandbox; staff trained on EIS error handling; downtime procedure documented and reviewed; and EIS monitoring dashboard accessible to responsible staff. Only proceed to production go-live after all items on this checklist are confirmed complete.
Conclusion
BIR EIS integration is a technical project with a clear path and defined deliverables. The key success factors are choosing the right integration approach for your system architecture, completing rigorous sandbox testing before go-live, and ensuring that every required data field is correctly populated in your integration. With the December 31, 2026 deadline close, businesses that have not yet begun their integration project must start immediately.
Nexright provides ERP, POS, and accounting software integration services for BIR EIS compliance. Our team has certified integrations with the major platforms in use across Philippine businesses. Contact us today for a technical assessment and integration roadmap.
Frequently Asked Questions
1. Can I use a direct EIS API connection without going through an accredited provider?
No. RR No. 11-2025 requires that all e-invoice submissions be made through a BIR-accredited service provider. Direct API connections to the BIR EIS without going through an accredited provider are not recognized as compliant, even if technically feasible. The accredited provider is a required intermediary in the compliance architecture. The exception is for businesses that go through the self-accreditation process to become their own accredited ESP — but this is a lengthy process not practical for most businesses with a December 2026 deadline.
2. How do I handle EIS submission failures at 2 am when my billing department is closed?
Your integration should implement automated retry logic for transient failures — situations where the EIS or provider API is temporarily unavailable. For persistent failures (repeated rejections due to data errors), an automated alerting system should notify responsible staff via email or SMS. Define an escalation path that includes a primary and secondary contact for after-hours EIS failures. Providers that offer 24/7 support are valuable for businesses with round-the-clock invoicing operations.
3. Does my accredited provider handle format updates when BIR changes the EIS specification?
Yes — one of the key value propositions of using an accredited provider rather than a self-built solution is that the provider handles BIR EIS specification updates on your behalf. When the BIR issues an updated data schema or API specification, the provider updates their gateway, typically without any changes required on the taxpayer’s side. Verify this by asking each provider you evaluate: who is responsible for implementing BIR EIS specification updates, what is the typical turnaround time, and how are you notified of changes?
4. How long should sandbox testing take?
For a typical SME with straightforward invoice types, sandbox testing should take one to two weeks. For larger businesses with multiple invoice types, complex VAT treatments, or high-volume POS environments, allocate two to four weeks for comprehensive sandbox testing. Do not rush the sandbox phase — discovering data errors in sandbox is far preferable to discovering them in production after real invoices have been transmitted with incorrect data.
5. What if my ERP has customer records without TINs?
This is one of the most common pre-integration data quality issues. Identify all customer records that lack TINs and implement a process for collecting and verifying TIN data before go-live. For existing customers, contact them directly for their TIN. For new customers, add TIN as a required field in your customer onboarding process. The BIR EIS requires a buyer TIN on all VAT invoices — without it, the submission will fail. Government entity customers typically have their own registered TINs; confirm these through official channels.
6. Can I integrate multiple billing systems from different parts of my business to one EIS account?
Yes. A single covered taxpayer entity can have multiple billing systems — for example, one ERP for service invoices and a separate POS system for retail sales — both integrated to the same EIS account through the same or different accredited providers. The EIS reference numbers are issued at the invoice level regardless of which source system generated them. Ensure that your invoice numbering sequences across different systems do not duplicate — each invoice must have a unique number within your registered series.
7. What does “EIS certification” mean and how do I get it?
EIS certification is the formal technical validation process confirming that your integrated system produces EIS-compliant submissions in the correct format with all required data fields. Certification is conducted in the BIR sandbox environment and is typically managed by your accredited provider, who submits a certification package to the BIR on your behalf. The certification confirms not just that data is being transmitted but that it passes all BIR validation rules. Retain the certification documentation as part of your permanent compliance record.
