Philippines BIR e-Invoice JSON Format: Schema, Fields & Validation Guide

The Philippines BIR e-invoice JSON format will follow a structured data layout to transmit invoices to the BIR's Electronic Invoicing System (EIS). Even if one field is wrong, your invoice risks rejection. Schema, mandatory fields, common errors you will come across and handling of invoices through the EIS API are what you should know before 31 December 2026 mandate.

Key Takeaways

• JSON, not XML, is the format the EIS accepts. BIR chose it as a lighter way to exchange data between different systems.
• Two schema variants exist: one for CAS, one for CRM/POS. Both sit at spec version v2.01.
• Every invoice has 24-character EisUniqueId having issuance date (8), EIS-Cert ID (8) and control value (8).
• The payload is JWS-signed, then AES-256 encrypted, then pushed to the API. Skip a step, and it fails.
• The deadline for covered taxpayers is 31 December 2026 under RR No. 26-2025. Micro taxpayers are exempt.

What is the BIR e-Invoice JSON Format?

The BIR e-invoice format becomes prescribed and structured-data layout for electronic invoices for Philippines taxpayers. They must raise and send to the EIS for reporting. These are mentioned under Sections 237 and 237-A of the Tax Code, implemented by RR No. 11-2025 and changed by RR No. 26-2025.

JSON or JavaScript Object Notation is machine-readable, so the EIS can validate and store your data without anyone manually entering it. A PDF or a scan of a paper invoice does not count after 31 December 2026.

Note that the Philippines e-invoice schema is not a digital picture of your invoice. Every value is checked server-side when fed. The authoritative field list lives on the EIS Certification Portal, with separate CAS and CRM/POS templates. Use the current v2.01 spreadsheet before you build anything.

Mandatory Fields in the BIR e-Invoice JSON Format

These are the e-invoice JSON fields Philippines businesses have to populate. Cardinality 1..1 means mandatory.

If a field does not apply, follow the null convention. String fields take null or blank. Number fields take 0.00. Do not leave them out.

A note most finance teams miss: the seller TIN is a plain 9-digit string. The branch code is its own field. Mapping the branch code into the TIN is a common configuration mistake, and it fails every invoice until you fix it.

BIR e-Invoice JSON Structure

The e-invoice JSON structure is organised into logical blocks under CAS v2.01:

1. Basic Information: EisUniqueId, IssueDtm, DocType, correction fields, remarks.
2. Seller Information: TIN, branch code, registered name, VAT type, address.
3. Buyer Information: TIN, branch code, registered name, address.
4. Sales / Amount Details: net sales after discount, VAT amount, tax classification, withholding.
5. Line Items (ItemList): each carries item name, quantity, unit cost, SalesAmt, discounts, NetSales.

The invoice body then sits inside a transmission wrapper. submitId identifies the submission. data holds the signed, encrypted invoice JSON. You can send 1 to 100 invoices per submission.

One document maps to one e-invoice JSON. Mixed transactions get split by tax classification, so a VATable and an exempt line on the same sale become separate e-invoices.

BIR e-Invoice Validation Rules

The BIR invoice validation rules run server-side. There is no partial pass. The EIS returns status codes.

That last one catches people. If your tax type is exempt or zero-rated, the VAT amount has to be 0.00. Anything else, and the payload bounces.

Common JSON Format Errors & Fixes

These are the ones that show up in almost every first live batch.

• Schema error (SYN004): a mandatory field is missing, or an extra one crept in. Validate against v2.01. Check numbers use 0.00, and strings respect max length.
• Invalid signature (SYN002): the JWS was signed with the wrong or an expired certificate. Regenerate before encrypting.
• Duplicate EisUniqueId (SYN003): the control value did not make the ID unique. Do not resubmit. Raise a correction document instead.
• Seller TIN error (ERR001): dashes in the TIN, or it is not registered. Use nine digits, no dashes.
• Datetime mismatch (ERR002): IssueDtm does not match the date baked into EisUniqueId. Align them.

JSON Validation Process: Pre-Submission Checklist

Run this before every batch. Not just during testing.

• Correct variant (CAS vs CRM/POS), spec v2.01.
• All 1..1 fields present. No redundant fields.
• EisUniqueId is 24 characters and unique.
• IssueDtm is YYYYMMDD and not later than transmission.
• Seller TIN is nine digits, no dashes, registered.
• Numbers use 0.00. Amounts in PHP. ItemList between 1 and 1,000.
• VAT is 0.00 for exempt or zero-rated.
• JWS signed, then AES-256 encrypted with the session key.
• submitId in the prescribed format. 1 to 100 invoices per submission.

BIR EIS API: JSON Submission

The Philippines e-invoice API integration runs on a push model over REST. There are four API types: Authentication, Invoice Issuance, Inquiry Result, and an optional Result Callback you host yourself.

The issuance flow, in order:

• Step 1: convert the CAS or POS invoice into JSON.
• Step 2: generate a signed JWS file.
• Step 3: AES-256 encrypt the JWS with your session secret key.
• Step 4: transmit the auth token plus the encrypted data.
• Step 5: EIS verifies and returns an encrypted receipt with a reference number.

On authentication and security, per the BIR EIS technical specifications, the auth token is valid for six hours. Every request header carries an HMAC-SHA256 signature, and the datetime must be within ten minutes of server time. RSA is used only once, in the auth request, to hand over your session key. Everything after that is AES-256.

Before any of this works, you need EIS Certification, an Application ID from the certification portal, sandbox testing, and a Permit to Transmit. The PTT is issued to the taxpayer, not the software vendor.