EazLink guide
How should a multi-branch retailer design BIR EIS integration?
A branch-aware design for taxpayer identity, POS events, central monitoring, connectivity and head-office reconciliation.
Updated 2026-09-06 by the EazLink team. Editorial review: EazLink Editorial Team.
Direct answer
A multi-branch design needs one transaction identity model across every store, explicit taxpayer and branch codes, a local handoff path when connectivity fails, and a central view of accepted, rejected and waiting documents. RR 11-2025 also states that when covered business activities are registered as a branch office, the head office and all branch offices are included, so legal scope and technical topology must be mapped together.
What to remember
- Map legal entities and branches before designing queues.
- Every store needs stable branch and terminal identity.
- Head office should see aging and repeated exceptions.
- A central platform does not remove the need for local continuity.
Central and branch responsibilities
A good design avoids making either side responsible for everything.
| Area | Branch | Head office |
|---|---|---|
| Sale capture | Owns the checkout event | Defines common data rules |
| Connectivity interruption | Persists the local handoff | Monitors queue age and patterns |
| Exception correction | Fixes local source data when assigned | Coordinates tax and system decisions |
| Evidence | Keeps document reference | Reconciles the full estate |
Start with a topology map
List legal entities, head offices, branches, warehouses, ecommerce channels, POS products and network conditions. Add the system that creates the official invoice for each path.
Do not use store names as identifiers. Names change; stable codes belong in every transaction and status record.
Measure branch reality
Peak volume, restart frequency and network outages matter more than average monthly invoices. Visit or interview the difficult stores.
Define what the cashier sees during an interruption and what head office sees after ten minutes, one hour and one business day.
One control plane, several adapters
EazLink can connect several POS or ERP sources to one status and reconciliation layer while each branch uses the adapter suited to its system.
That does not mean every store must have identical hardware. The common part is transaction identity, rules, status and evidence.
Branch rollout sequence
- Map entities, branches and source systems.
- Pilot one normal and one difficult branch.
- Test peak load and connectivity loss.
- Train cashiers and central support separately.
- Roll out in groups with daily reconciliation.
Quick questions
Can head office transmit for every branch?
The technical topology can be centralized, but each transaction still needs the correct taxpayer and branch identity and must follow the approved process.
Does every branch need hardware?
No universal answer applies. Use local hardware where continuity, connectivity or certificate handling requires it.
What should the rollout dashboard show?
At minimum, accepted, rejected, queued and unknown documents by entity, branch, age and source system.
Continue the preparation
Sources and verification
Check the current BIR rules and portal notices before making a compliance decision.