EazLink guide
What should developers prepare for BIR EIS JSON and JWS testing?
A safe technical checklist for structured invoice data, signing boundaries, credentials, validation and traceable test evidence.
Updated 2026-09-06 by the EazLink team. Editorial review: EazLink Editorial Team.
Direct answer
Developers should prepare a stable invoice data model, representative JSON payloads, a controlled signing boundary where required by the current technical specification, secure credential handling, repeatable tests and complete response logs. Do not guess algorithms, headers or certificate rules from an old example. Use the technical documents issued for the taxpayer's current BIR certification environment.
What to remember
- Separate the business invoice model from the transport payload.
- Private keys and production credentials should not appear in logs or test files.
- Validation errors need field-level explanations.
- The active BIR technical specification is the authority for cryptographic details.
Technical artifacts to keep separate
Combining these artifacts makes debugging and security review harder.
| Artifact | Purpose | Handling |
|---|---|---|
| Business invoice model | Stable source meaning | Version with the application |
| BIR JSON payload | External data contract | Generate and validate per specification |
| JWS or signature material | Integrity and authentication where required | Keep keys in controlled storage |
| Response log | Evidence and diagnostics | Redact secrets and personal data |
Map meaning before syntax
JSON can be valid while the invoice is wrong. Define how discounts, VAT, zero-rated lines, adjustments, branch identity and buyer information work in the source system.
Then map that model to the current external schema. This order makes later specification changes easier to absorb.
Put signing behind a narrow interface
Where the approved specification requires signing, application code should request a signature from a controlled component instead of reading private key files directly.
Test teams should use dedicated test credentials. Logs may contain key identifiers and result codes, but never secret material.
Make validation useful
Return the field, rule and source value for a failed precheck. A message such as invalid payload sends developers hunting through the entire document.
EazLink can centralize this validation and response history while each ERP or POS adapter keeps responsibility for its source data.
Developer readiness list
- Obtain the current technical package.
- Build representative test fixtures.
- Separate mapping, signing and transport code.
- Redact logs and secure credentials.
- Record payload and response versions for each test.
Quick questions
Is JSON alone an electronic invoice?
JSON is a structured format. The complete electronic invoice and reporting process still depends on the legal and technical requirements in scope.
Can developers copy a JWS example from the internet?
Use examples only for orientation. The active BIR specification and certification environment determine the required implementation.
Should production private keys be used in a sandbox?
No. Keep test and production credentials separate and follow the official security procedure.
Continue the preparation
Sources and verification
Check the current BIR rules and portal notices before making a compliance decision.