EazLink guide
Does BIR EIS work offline, and what happens during API downtime?
Separate local sales continuity from later electronic transmission, and design a queue that does not lose or duplicate invoices.
Updated 2026-09-06 by the EazLink team. Editorial review: EazLink Editorial Team.
Direct answer
A BIR API cannot receive a transaction while the connection or service is unavailable. A business can design local capture, queuing and controlled recovery around that interruption, subject to the rules that apply to its invoice process. The queue must preserve the source transaction, distinguish timeout from rejection and prevent a retry from creating a duplicate.
What to remember
- Offline capture is not the same as offline transmission.
- A timeout leaves an unknown state until checked.
- Every queued item needs a stable source reference and retry history.
- BIR advisories belong in the operating procedure.
What each failure state means
Operations should not treat every unsuccessful screen message as the same problem.
| State | Meaning | Next action |
|---|---|---|
| Queued locally | Not yet submitted | Wait for the approved retry condition |
| Timed out | Submission result is unknown | Check status before resending |
| Rejected | Service returned a business error | Correct data and follow the approved process |
| Accepted | Submission completed | Store proof and reconcile |
Design the queue as a ledger
A reliable queue records when the transaction entered, every attempt, the response and the operator action. Deleting an item because it looks old destroys the audit trail.
Use idempotency controls tied to the source invoice. A retry should continue the same document story.
Give branch staff a small set of actions
Cashiers should see whether they can continue, whether the document is waiting and whether support must intervene. They should not choose technical retry modes.
Head office needs a consolidated view of aging queues, repeated rejections and branches with connectivity trouble.
EazLink continuity controls
EazLink can keep a visible local or central queue, apply controlled retries and return the final status to the source system. Hardware can support branches where local continuity is needed.
The final design must follow the taxpayer's approved process and current BIR instructions during service incidents.
Downtime runbook
- Define queue persistence and retention.
- Separate queued, timed-out and rejected states.
- Set duplicate-safe retry rules.
- Assign branch and head-office actions.
- Monitor official BIR advisories.
Quick questions
Can an invoice be transmitted with no internet?
No external API transmission can occur without connectivity. The system may preserve work locally and transmit later if the approved process allows it.
Should a timeout be retried immediately?
Not blindly. First determine whether the earlier request was received, then follow the approved recovery rule.
Does EazLink guarantee BIR availability?
No. It provides operating controls around interruptions; it does not control government or network availability.
Continue the preparation
Sources and verification
Check the current BIR rules and portal notices before making a compliance decision.