Connect governed fiscaldocuments to supportednetworks and authorities.
Build on approved adapter architecture for invoice-related workflows. Production support varies by country, network and capability—and must be verified in Coverage.
.png&w=48&q=75){kind=small}
This page explains public adapter patterns. Exact network/authority contracts, document formats, credentials, status mappings and production availability remain governed by approved technical and coverage sources.
This is developer-facing architecture and implementation guidance for connecting governed invoice-related workflows to approved external networks and authorities. ZoikoTax adapters apply supported transformation, routing and integration logic within an enterprise workflow.
A pattern alone never confirms production support.
One workflow. Distinct responsibilities.
Keep business context, adapter behavior and external decisions separate—then connect approved states and evidence to the teams that need them.
Owns the invoice and business context. ZoikoTax does not replace the enterprise ERP or BSS.
Applies supported transformation, routing and integration logic under the exact approved adapter contract.
Owns regime-specific acceptance, validation, clearance, reporting or acknowledgement. These are not universal obligations.
Consumes approved states and evidence within the enterprise workflow. Downstream use does not change the external authority’s decision.
Preserves supported request, response and version trace across the workflow for investigation and reconstruction.
Read the flow as: source context ↔ supported adapter logic ↔ external response; approved states continue to finance/compliance, while supported traces are preserved in evidence. Arrows show data/control flow, not guaranteed synchronous execution.
Coverage owns exact country, network, capability and environment support. The technical adapter owner governs formats, endpoint/schema, credentials, certificates, signatures, transport, external behavior, mappings, timing and retries. Architecture creates no universal legal obligation.
A governed path, not a universal protocol.
Prepare → Transform → Validate → Route → Submit → Receive → Normalize → Evidence. A normalized pattern does not mean every external authority follows identical steps.
Use the governed source schema; do not infer a public production payload.
Document formats and field mappings come only from exact adapter documentation.
Supported validation is not an assertion of legal correctness.
Country, network, capability and environment routing are Coverage-controlled.
Submission behavior and requirements are defined by the adapter’s technical contract.
External codes and timing remain source-defined; absence of a response is unresolved.
Normalized meaning must retain its original adapter context and mapping source.
Keep versioned context and sanitized diagnostics within approved visibility boundaries.
The numbered text above is the diagram’s ordered equivalent. It describes conceptual purposes and boundaries, not a mandatory sequence, a legal timing rule or a published network protocol.
Different patterns. Different meanings.
Clearance, reporting, validation and acknowledgement are distinct families. Their steps and effects must be read in the approved adapter’s regime-specific context.
An external clearance decision may be part of the governed lifecycle. Do not infer universal pre-clearance, legal timing or an approval guarantee.
A reporting step conveys required information under the applicable contract. Reporting is not automatically clearance or acceptance.
Defined checks can produce a validation result. Passing technical validation does not independently establish legal correctness.
An acknowledgement may confirm receipt or processing progress. It is not a final outcome unless the approved adapter explicitly defines it that way.
Several external steps may coexist, with distinct acknowledgements and final states. Do not collapse them into one universal lifecycle or infer a country or regime.
Read as conceptual state families, not a universal exact sequence: prepared and submitted context may lead to an awaiting-source state; an outcome exists only when the approved source defines and supplies one. Branches, intermediate steps and timing vary by adapter.
These families do not assert any country’s legal obligations, universal pre-clearance requirements or current production coverage. Validation must never be presented as proof of legal correctness.
Receipt is not the final outcome.
External response → approved mapping → governed normalized status → downstream consumption. Keep the original
adapter context accessible throughout.
Indicates receipt only to the extent the exact
adapter defines it. Receipt must not be rendered
as acceptance or clearance.
May describe progress or a processing step. It is
distinct from a final decision and retains its
adapter-specific meaning.
Consume only the meaning approved for the
exact external response and mapping. There is
no universal status taxonomy.
A clearance outcome only when defined by
the approved adapter.
A reporting outcome only when defined by
the approved adapter.
An acceptance outcome only when defined
by the approved adapter.
A rejection outcome only when defined by
the approved adapter.
No response is neither rejection nor success. Do not fabricate codes, response times or currentness. Publish an exact-source timestamp only when supplied and approved;
otherwise currentness is not published.
Link the context. Keep the payload private.
Correlate enterprise source, request, fiscal document, external response and evidence without exposing invoice
content or private identifiers.
Neutral placeholders do not assert an identifier format, required field, actual value or API schema. Exact mappings and display rights are controlled by the adapter documentation.
Investigate before you retry.
Recovery is a contract-specific decision. Confirm the current approved state before choosing a permitted next action;
never assume blind retry or automatic resubmission is safe.
First investigate the approved state, then consult the exact contract and evidence. Proceed only with a supported, legally permitted recovery action. If state or source is unknown, keep
the uncertainty explicit and investigate rather than submit again.
Use approved retry semantics only. Counts,
backoff and timing are not prescribed here;
consult the exact API and adapter contract.
Use documented idempotency and correlation
behavior. Do not infer a universal duplicate-
prevention guarantee.
No response is not confirmed acceptance or
rejection. Investigate source state before any
further submission.
Interpret rejection through exact API/adapter
documentation. Correct only the governed
issue; no sample response code is implied.
Use an approved status query or recovery route
only where supported. Preserve intermediate
and external context.
Lifecycle and legally permitted resubmission
remain source-controlled. Do not infer automatic
legal compensation or reversal.
Duplicate handling, retries and resubmission must defer to exact adapter contracts and legally permitted behavior. A general integration pattern never establishes permission to
submit a document again.
A trace you can investigate. A context you can reconstruct.
Preserve the supported chain from source context to external response without turning a public example into a real
invoice or a claim of legal proof.
Keep versions, response meaning and supported state history together. Do not silently reinterpret a historical outcome through a newer mapping.
Evidence supports investigation and reconstruction within approved boundaries. Access rights and supported replay behavior remain governed by the relevant platform and adapter sources.
.png&w=32&q=75){kind=small}
Approved linkage to the enterprise source; no sensitive source record is shown.
Supported transformation context and its pinned version.
Supported request, adapter, timestamp and destination context.
Approved response and its original adapter-specific meaning.
State transitions preserved with their historical interpretation.
Adapter, content and rule versions used for that historical context.
An approved route for reconstruction, subject to access and visibility.
No payloads, taxpayer/customer/tenant identifiers, authority references, secrets, tokens, certificates or private
environment data are shown.
A supported trace can help reconstruct what happened. It does not independently prove correctly interpreted law or guarantee an authority outcome.
Architecture does not mean availability.
Coverage is the first-class gate for exact country, network, capability and environment support. No approved registry
is supplied on this architecture page.
supported
combination.
Country/jurisdiction + approved network/
authority adapter + specific e-invoicing/
CTC capability + environment + governed
effective date.
A managed service, production entitlement or
authority acceptance must not be inferred from a
pattern, pilot or test result.
Only if expressly approved in Coverage.
A distinct, governed evaluation scope.
Defined validation activity, not live entitlement.
Exploration, not a support commitment.
No published Coverage or no matching coverage means support is not confirmed. An unavailable adapter, missing source or stale mapping must remain explicit; consult current
Coverage and approved technical sources rather than filling the gap with an availability claim.
Test the contract. Verify readiness separately.
Start with approved documentation, then use a non-production Sandbox only where separately available. Test with
synthetic or approved data—not public invoice payloads.
test path.
Review the API contract and adapter
guide. Verify Sandbox availability,
exercise approved async behavior, and
use governed negative tests with
synthetic or approved data.
Check current Coverage again before production. Test
availability, credentials, delivery and recovery
semantics must come from their approved sources;
none is established by this page.
Verify the exact country/network/capability/environment combination.
Confirm separately available non-production testing and its scope.
Use the exact approved requirements through controlled configuration.
Link source, request, document, external response and evidence.
Preserve response meaning; implement permitted recovery behavior.
Confirm traceability, access and accountable operating teams.
Complete the applicable technical, Coverage and security gates.
A completed test does not prove entitlement, live Coverage or authority acceptance. Verify approved support and obtain the required release approvals before production use.
Sensitive configuration stays out of public content.
Use only approved transport and adapter-specific trust requirements. This architecture page publishes no credentials,
assurance badge or invented security protocol.
Credentials are never public. Certificates and
signatures are conditional on the exact
approved adapter requirements—not universal
prerequisites.
Use approved transport and the minimum
required data. Do not expose sensitive payloads
or private environment details in logging or
examples.
Keep diagnostics sanitized and detail access-
controlled. No secret, token, certificate, invoice
identifier or authority reference belongs in
public content.
Use the approved Trust source for security, privacy and assurance context. No certification, compliance or uptime claim is inferred here.
Move from discovery to governed operation.
Discover → Verify Coverage → Map → Configure → Test → Observe → Approve → Operate. The numbered guidance is
the full text equivalent of the journey.
Read the API contract, integration
guides and approved adapter
documentation.
Confirm exact adapter, capability
and environment support in
current Coverage.
Map the source document and
conceptual correlation to the
governed contract.
Control routing and credentials
using approved technical
requirements.
Use separately available non-
production tests and governed
negative cases.
Inspect approved statuses,
recovery behavior and supported
evidence.
Complete technical, Coverage,
security and applicable regulatory
gates.
Monitor, recover, reconcile and
preserve evidence under
approved contracts.
This journey promises no onboarding, approval, authority response or activation time. Source-approved technical behavior, Coverage and security remain distinct responsibilities;
public content cannot originate those facts.
Unknown stays unknown. Guidance stays useful.
Illustrative documentation specimens—not live service records. Status is stated in text, and essential guidance does
not depend on color, hover or animation.
Patterns explain boundaries; they do not confirm
current support.
No approved entry is available here. Do not infer
production availability.
Do not route through an unavailable path or substitute
an unapproved one.
Mapping or contract context is missing. Keep the
unknown visible.
No response is not rejection or success. Investigate
approved state first.
Public diagnostics remain sanitized; credentials and
private payloads stay hidden.
No approved final meaning is supplied. Never render an
unknown as accepted.
Do not publish an outdated interpretation as current.
Preserve historical context.
1 Source owns context; 2 Adapter applies supported
logic; 3 External party owns its outcome; 4 Teams
consume states; 5 Evidence keeps trace.
.png&w=32&q=75){kind=small}
Investigate current approved state before retrying. The required recovery
guidance remains visible; no private incident or credential detail is disclosed.
Direct answers. No inferred coverage.
Implementation guidance stays tied to approved technical and Coverage sources.
Approved adapters connect governed invoice-related workflows through supported transformation, routing, submission and response handling. Source
systems retain business context; external networks or authorities own their defined outcomes. The exact contract governs implementation.
No universal support is implied. Verify the exact country/jurisdiction, approved network/authority adapter, capability, environment and effective date in
current Coverage. A public architecture pattern does not establish production availability.
Source-controlled external responses pass through approved mappings to governed normalized statuses, with original adapter context retained.
Receipt, processing acknowledgement and final outcome remain distinct. Unknown or awaiting-source must not be rendered as success or rejection.
Investigate current approved state and evidence before retry. Use only documented idempotency, correlation, recovery and legally permitted
resubmission behavior. Retry counts, timing, duplicate guarantees and automatic legal compensation cannot be inferred from this page.
Start with the API contract and integration guides. Use a non-production Sandbox only where separately available, with synthetic or approved data and
governed negative tests. Consult Webhooks & Events for exact async semantics. There is no live test or activation claim here.
Verify approved adapter Coverage and test availability; map identifiers; confirm governed credentials, status/recovery handling, evidence and
operational ownership; then obtain required technical, Coverage and security approvals. Sandbox completion alone proves neither entitlement nor
authority acceptance.
Start with the contract. Verify the path.
Technical documentation first. Availability, assurance and evidence remain separate source-bound checks.
The governed API contract and
supported integration surface.
Implementation guidance and
approved adapter boundaries.
Exact async schema and delivery
semantics.
Non-production testing where
separately available.
Verify exact availability · /coverage/
Review approved assurance · /trust/
Investigate historical context · Approved platform context
Book a Demo for contextual enterprise qualification—not self-service activation, live testing or a promise of network support. /demo/
