EazLink guide
What are the common BIR EIS integration test failures?
A practical failure map for source data, payload validation, authentication, duplicate handling and response reconciliation.
Updated 2026-09-06 by the EazLink team. Editorial review: EazLink Editorial Team.
Direct answer
Most integration failures fall into a few technical buckets: missing or inconsistent source data, incorrect mapping, authentication or certificate problems, duplicate or replay behavior, and poor handling of timeouts or service responses. The exact error codes come from the active BIR environment. Teams should keep a test record that links each response to the source transaction and payload version.
What to remember
- Classify failures before fixing them.
- Keep source data, payload, response and code version together.
- A timeout is not proof of rejection.
- Never solve a duplicate by inventing a new invoice identity.
Failure categories
The category points to the team that can fix the problem.
| Category | Typical symptom | First owner |
|---|---|---|
| Source data | Required value missing or inconsistent | ERP, POS or master-data team |
| Mapping | Wrong field, format or calculation | Integration team |
| Authentication | Credential, certificate or access failure | Security and onboarding owner |
| Transport or service | Timeout or unavailable endpoint | Operations team |
| Duplicate handling | Repeated document or uncertain prior result | Integration architect |
Build a failure record
Every failed test should keep the source ID, payload hash or version, environment, submission time, response and person who changed the next attempt.
Without that record, teams repeat tests with slightly different data and cannot explain why one passed.
Fix the right layer
A missing customer tax field belongs in source data or master-data procedure. A wrong JSON property belongs in mapping. A timeout belongs in operations and recovery.
Patching all three in one script may get a demo through, but it creates a support problem after launch.
Use validation before transmission
EazLink can run field and calculation checks before calling the external interface, then preserve the official response separately.
Prechecks reduce avoidable failures. They do not replace the BIR test or guarantee that a payload will be accepted.
Test evidence checklist
- Use fixed, representative test cases.
- Record the source and payload version.
- Classify every failure by layer.
- Retest the original case after a fix.
- Keep negative tests in the regression suite.
Quick questions
Can an integration translate every BIR error automatically?
It can explain known validation and response codes, but current official documentation and human review remain necessary for new or ambiguous errors.
Should rejected data be edited in middleware?
Correct the system that owns the bad data where possible. Silent middleware edits make the accounting and transmitted records diverge.
What is the hardest failure to handle?
An unknown result after a timeout needs careful status checking and idempotent recovery because blind resubmission can create duplicates.
Continue the preparation
Sources and verification
Check the current BIR rules and portal notices before making a compliance decision.