The EIS JSON / JWS format: what a structured e-invoice really is
The reason a PDF is not an e-invoice comes down to format. The BIR's Electronic Invoicing System is built around structured JSON, signed with a JSON Web Signature and sent by API. Here is what each of those means, without the jargon.
Key Takeaways
- An EIS e-invoice is a JSON payload aligned with the BIR's EIS schema — machine-readable fields, not a picture.
- It is signed with a JSON Web Signature (JWS): the taxpayer signs with a private key; the BIR verifies with the public key.
- It is transmitted by API — near real time, and within 3 calendar days of the transaction once electronic sales reporting applies (RR 8-2022).
- A PDF or scan is not structured data — it cannot be validated automatically, so it does not qualify.
What format does the EIS require?
Structured JSON aligned with the BIR's EIS schema. Each invoice is generated as a JSON payload of machine-readable fields — seller, buyer, line items, amounts, and tax — that the BIR can validate automatically. This is what “structured invoice data” in RR 11-2025 means in practice.
| Layer | What it is | Why it matters |
|---|---|---|
| JSON payload | Machine-readable invoice fields in the EIS schema | The BIR can validate every field without OCR |
| JSON Web Signature (JWS) | Cryptographic signature over the JSON | Proves the data was not tampered with |
| API transmission | System-to-system send to the BIR | Near-real-time electronic sales reporting |
What is a JSON Web Signature (JWS)?
A JWS is a digital signature applied to the JSON invoice. The taxpayer signs the payload with a private key; the BIR checks it against the corresponding public key to confirm the invoice is authentic and unaltered. It is the tamper-evidence layer that lets the BIR trust structured data it received over the wire.
Why a PDF can never satisfy this
A PDF is pixels arranged to look like an invoice; a computer cannot reliably extract every field from it. The EIS needs signed, structured JSON it can parse and validate. That is why RR 11-2025 classifies an invoice without electronic-reporting capability as a traditional manual invoice — the format, not the appearance, is what counts.
This is also why “we email PDFs” is not compliance. For the registration side, see CAS vs EIS; for the readiness path, how to become EIS-ready; and for the marketing trap, “EIS-ready” vs “BIR-accredited”.
Frequently asked questions
The EIS is built around structured JSON data aligned with the BIR's EIS schema. Each invoice is generated as a JSON payload, signed with a JSON Web Signature (JWS), and transmitted to the BIR via API — near real time, and no later than three days after the transaction once electronic sales reporting applies.
A JWS is a cryptographic signature applied to the JSON invoice payload. The taxpayer signs it with a private key; the BIR verifies integrity and authenticity with the corresponding public key. It proves the invoice data was not tampered with in transit.
A PDF is a picture of an invoice — a computer cannot reliably read every field without OCR. The EIS needs structured JSON data it can validate automatically. Under RR 11-2025, an invoice that cannot be electronically reported does not qualify as an electronic invoice.
To transmit, a taxpayer's system must demonstrate it can generate EIS-schema JSON, apply a valid JWS, and integrate with the BIR's API. This certifies the taxpayer's implementation for transmission — it does not make the vendor's product “BIR-accredited.”
Structured JSON, signed and ready — not PDFs.
NexusWorkforce generates EIS-format invoice data from your DTR-driven billing, ready to sign and transmit when the EIS requires it — with a readable copy alongside, never instead of, the real record.
Book a demo