Connect billing decisions without rebuilding your BSS.
Integrate ZoikoTax into quote, commit, transaction and invoice flows while preserving clear system ownership and governed fiscal evidence.
Read architecture here. Resolve exact contracts in the docs.
This page explains the integration model. Exact request/response contracts, authentication, versioning, error semantics and availability remain governed by approved developer documentation and release sources.
What is a Billing & BSS integration?
Public architecture and implementation guidance for connecting billing/BSS transaction, quote, commit and invoice context with supported ZoikoTax fiscal decisions and evidence. Keep the systems you operate; integrate the fiscal responsibilities you need.
Not a BSS replacement.
Not a production contract, ERP ledger or universal e-invoicing workflow. Availability is capability-specific.
Keep ownership explicit at every handoff.
One integration model. Distinct responsibilities. No transfer of your billing, accounting or customer workflow ownership.
Billing / BSS
Offer · Rating · Orchestration · Invoice
Owns enterprise offers, rating, orchestration, invoice composition and customer-facing workflows. Billing presentation does not become fiscal authority.
ZoikoTax
Determination · Obligations · Evidence
Provides supported fiscal determination, obligations and governed evidence. The authoritative fiscal decision is distinct from its presentation in billing; approved contracts define its meaning.
ERP / GL
Accounting · Posting
Retains accounting and posting ownership as the system of record. Fiscal outcomes can inform approved downstream mappings, not replace ledger controls.
E-invoicing / network
Approved transport · Authority workflow
External approved authority or network transport and workflow vary by Coverage. E-invoicing and CTC have a separate integration route and responsibility boundary.
Evidence / audit
Outcomes · Versions · Linkage
Traces approved outcomes, rule/content versions and supported transaction/document linkages. Evidence supports investigation; it is not compliance proof.
Information flow is not synchronization or deployment topology.
Billing supplies approved facts → ZoikoTax evaluates supported fiscal responsibilities → approved outcomes inform billing, downstream systems and evidence. External authority/network workflow remains separate. No vendor or deployment support is implied.
Preview is prospective. Commit is authoritative.
Sequence the fiscal decision before composing the downstream billing outcome.
Conceptual sequence — exact semantics remain contract-defined.
Quote / preview
Prospective evaluation. Not an authoritative commit.
Decision context
Relevant approved facts for a supported fiscal decision.
Commit
Authoritative binding only under approved semantics.
Invoice / downstream
Billing composes the invoice; each system owns its workflow.
Evidence
Preserve the decision trace and applicable versions.
Quote/preview evaluates prospective context. Exact persistence and expiry are API-defined; preview must not be treated as a committed outcome.
Prepare relevant approved facts and decision context. Mutations and timing must follow the documented contract rather than local assumptions.
Commit binds an authoritative decision only under approved semantics and contract-defined idempotency. Reversal and financial finality are not inferred here.
Billing owns invoice composition and customer presentation. Downstream accounting and authority/network workflows retain their own responsibilities.
Retain approved version and trace references across supported linkages. Do not silently substitute a current decision for historical context.
Separate state context, not just visual color.
Quote = prospective preview. Commit = authoritative decision under the approved contract. Neither label defines an expiry window, persistence guarantee, reversal rule or financial-finality policy.
Choose the pattern. Verify the contract.
Availability is gated by the approved capability, operating mode and developer sources—not by this illustrative matrix.
Synchronous request / response
Documented mode only · no latency guarantee
WHEN TO USEA billing flow needs a documented fiscal evaluation within its request/response path.
Approved transaction or quote/commit context and supported references.
Supported fiscal decision/outcome and evidence references under the exact contract.
Asynchronous workflow
Only when explicitly approved
WHEN TO USEThe approved capability supports work and subsequent continuation outside the immediate request.
Approved context, workflow identity and supported correlation.
Documented state/outcome references and supported continuation context.
Bulk / batch
Exact limits and semantics belong to batch docs
WHEN TO USEA documented bulk capability fits grouped evaluation or reconciliation needs.
Approved grouped context and item identities using the exact batch contract.
Supported item/group outcomes and documented partial-result references.
Event-driven continuation
Availability and delivery are contract-defined
WHEN TO USEAn approved event contract supports a downstream billing continuation.
Supported correlation and approved consumer configuration; no schema is defined here.
Approved notification context, with exact schema and delivery defined in event docs.
Shadow / parallel evaluation
Non-impacting · no production changes
WHEN TO USECompare supported outcomes alongside an incumbent before governed cutover.
Approved comparison context, mappings and stable comparison references.
Supported comparison evidence and differences for investigation.
Enterprise context
Approved facts and supported identity
Supported evaluation
ZoikoTax fiscal decision under the contract
Owned continuation
Billing/downstream workflow plus evidence linkage
Text equivalent: the enterprise provides approved context; ZoikoTax evaluates supported fiscal functions; the receiving system follows its own approved continuation. Shadow comparison must not change production outcomes and does not establish legal correctness.
A pattern is not an availability or performance promise.
Follow exact API, event or bulk documentation for approved modes and their boundaries. No endpoint, payload, latency, throughput, timeout threshold or service-level commitment is specified here.
Link the decision. Let billing present it.
Fiscal authority and invoice presentation are separate responsibilities.
Billing transaction identity
Supported fiscal decision
Billing-owned invoice reference
Reconciliation / evidence linkage
Text equivalent: supported transaction and fiscal references can link to billing-owned invoice and reconciliation/evidence records where supported.
Identity linkage
Link supported transaction and fiscal decision identity to invoice/document and evidence references. Exact formats remain API-defined.
Line presentation
Tax/fee line presentation is conceptual here. Billing applies governed mappings; no invoice amounts or production line schema are implied.
Corrections & adjustments
Use governed correction/adjustment references. Do not infer reversal, mutation or financial-finality rules from the illustration.
Reconciliation
Connect approved transaction, invoice, filing, remittance and accounting concepts without transferring system-of-record ownership.
ZoikoTax does not own invoice rendering, billing-account state or every posting.
E-invoicing / CTC is a separate integration path. External authority/network transport and workflow vary by Coverage; ERP remains the accounting system of record.
Map the meaning before mapping the fields.
Conceptual categories—not a production schema, real values or customer-specific settings.
| CONCEPTUAL CATEGORY | GOVERNED MAPPING | IMPLEMENTATION BOUNDARY |
|---|---|---|
| Product / service | Controlled fiscal classification | Map approved product/service concepts to controlled fiscal classification. No customer-specific configuration is shown. |
| Transaction | Stable identity & relevant facts | Supply supported stable transaction identity and relevant approved facts. Exact identity and fact schemas belong to the API. |
| Customer / party | Required approved categories only | Use only approved party categories needed for the supported capability; avoid unrelated personal information. |
| Location / jurisdiction | Capability-specific context | Map location and jurisdiction facts only as required by the approved capability and Coverage. |
| Invoice / document | Supported linkage | Connect invoice/document references to supported transaction, fiscal outcome and evidence identities. |
| Correlation / external IDs | Exact format is API-defined | Use stable approved correlation references. This page specifies neither identifier values nor formats. |
Data minimization is part of the integration boundary.
Send only required facts. Never place secrets or unnecessary PII in free-text fields. Approved API contracts and governed Privacy handling—not this conceptual category list—determine what may be transmitted, stored or referenced.
An uncertain transport result is not a fiscal answer.
Recover from governed state. Never blindly infer commit success—or failure—from a disrupted exchange.
Uncertain transport
Result is unknown. Do not assume the commit state.
Consult governed state
Use documented current-state lookup / reconciliation.
Contract-defined recovery
Proceed only from the approved result and recovery rules.
If state, source or currentness is unknown → hold the assumption → review the approved source and integration owner guidance. Never improvise a retry or compensation.
Text equivalent: when transport is uncertain, consult governed current state/reconciliation; then apply documented recovery. If the required source is unknown, stop inference and seek review.
Duplicate requests
Use duplicate-safe, contract-defined idempotency. Exact key format, scope and retention are API-defined; none are specified here.
Retry / backoff
Use the approved retry/backoff documentation. Do not invent timing, counts, retryable codes or compensation rules.
Timeout / uncertainty
Transport uncertainty is not an authoritative fiscal state. Check governed current state or reconciliation before deciding what happened.
Validation
Interpret validation through the exact error contract. Missing or unknown source semantics require review, not a guessed fix.
Partial failure
Reconcile supported item/status references and documented status lookup. Do not guess compensating actions or assume all-or-nothing behavior.
Correlation
Carry stable approved correlation references through requests, status review, evidence and safe support escalation. Avoid sensitive payloads.
Unknown contract → review required
Where an exact technical source is missing or not confirmed current, retain the conceptual guidance and route to the approved documentation. No error code, timeout, retry schedule or authoritative outcome is inferred.
Continue the workflow. Preserve the reference.
Use asynchronous continuation only where the approved capability and event contract support it.
Fiscal / request context
A conceptual supported workflow context—not an event name.
Approved notification
Schema and delivery semantics belong to the event contract.
Downstream billing consumer
Follow owned workflow and preserve supported evidence linkage.
Text equivalent
Conceptual fiscal/request context leads to an approved notification, then to a downstream billing consumer and supported evidence linkage. Use public-safe category placeholders such as “transaction reference”, “decision reference” and “correlation reference”—not actual IDs.
Exact schema, delivery, verification algorithm and retry behavior are owned by this documentation.
No delivery or verification mechanism is asserted here.
This illustration does not promise exactly-once or at-least-once delivery, prescribe a signature mechanism, identify event names or expose credentials. Resolve these details from the approved, current event contract.
Make the decision trace a first-class artifact.
Evidence is for reconstruction and investigation—not a decorative compliance badge.
Decision evidence anatomy
Decision identity
Approved reference category; no actual identifier shown.
Rule / content versions
Pinned versions that explain the decision’s historical context.
Input context
Required approved fact context, without sensitive payloads.
Outcome linkage
Supported transaction, fiscal and invoice/evidence connections.
Replay context
Supported historical replay and its governed references.
Keep history explicit. Never silently substitute currentness.
Preserve pinned rule/content versions and the approved input context associated with a decision. Historical replay is supported only under its documented capability and semantics.
Use approved investigative references across systems. Do not expose sensitive facts, private topology, actual IDs or invented version numbers in public examples.
Billing transaction
Owned transaction context
Fiscal decision
Supported decision & pinned versions
Invoice / reconciliation
Approved document and outcome linkage
Evidence
Governed investigative audit path
Traceability supports an audit path; it is not legal or compliance proof.
Text equivalent: billing transaction → fiscal decision → invoice/reconciliation → evidence. Preserve approved historical references and distinguish historical replay from a current evaluation. No actual records or sensitive payloads are shown.
Compare before cutover. Preserve control throughout.
Connect around the incumbent architecture, including federated coexistence where approved.
Discover
Inventory dependencies and current ownership.
Map
Review products, facts, identities and destinations.
Connect
Controlled non-production integration.
Compare
Shadow evaluation without production changes.
Reconcile
Investigate differences and close reference gaps.
Approve
Governed evidence and readiness gates.
Cut over
Explicitly approved authority and workflow change.
Operate
Maintain owned controls, traceability and review.
Ordered text equivalent
Discover → Map → Connect controlled non-production → Compare → Reconcile → Approve → Cut over → Operate. Inventory dependencies and map products, facts, identities and destinations. Preserve existing authority until an approved transition; investigate gaps before readiness gates.
Shadow does not change production.
Compare supported outcomes alongside existing engines without affecting production decisions. Agreement does not establish legal correctness. Incumbent and federated coexistence remain possibilities only where approved.
A governed transition—not an automatic migration.
No zero-risk, rip-and-replace, automatic migration or guaranteed rollback claim is made. Approval, cutover and ongoing operation depend on the applicable sources, capability readiness and owned enterprise controls.
Test the contract. Verify the capability.
Non-production learning is not production authorization. Start with the authoritative technical sources.
Before a production decision
Review checklist · not a completed readiness assessment
Named integration owner and responsibility boundaries
Governed environment and credentials confirmed through approved docs
Reviewed product/service mapping and required fact categories
Transaction identity and correlation strategy reviewed
Errors, retry and reconciliation mapped to approved contracts
Evidence and downstream references connected where supported
Capability-specific Coverage verified before production
Authentication, environment and exact contracts are authoritative here.
Non-production testing where available; no active environment is implied.
Use documented event testing and exact continuation contracts.
Use approved batch test and partial-outcome guidance.
Review approved Shadow comparison and integration sequencing.
Confirm capability-specific readiness before production.
Test results do not guarantee go-live readiness.
Use governed environment and credential guidance from the approved sources. No real credentials, active sandbox availability or testing-to-production guarantee is shown. Coverage and owned approval gates remain separate.
Keep sensitive context out of public surfaces.
Follow approved transport, Privacy handling and Trust evidence. Do not infer controls or assurances from a diagram.
No exposed secrets
Never place secrets in URLs, screenshots, analytics or examples. Use approved transport only. This page contains no operational credential screen.
Required context only
Supply only required approved facts. Apply governed PII handling and Privacy guidance; do not add unnecessary PII to free-text fields or sensitive logs.
Safe support references
Use approved correlation references for investigation and support. Share no sensitive payloads. Trust claims must follow approved evidence—not invented certification, uptime or control guarantees.
Public-safe examples and references only
Keep billing, customer, tax, invoice, secret and free-form technical data out of public examples and analytics. Evidence references are investigative context, not an assertion of compliance.
A docs-first path, even when the answer is unknown.
Choose the review path for your role. Missing metadata should produce a safe next step—not invented technical truth.
Resolve the implementation
API Reference → Integration Guides → Sandbox where available. Map identities, errors, recovery and evidence to approved contracts.
Preserve system ownership
Responsibility model → pattern selection → coexistence and downstream mapping. Keep billing, ERP and authority workflows distinct.
Approve from sources
Coverage → evidence and Trust review → governed approval gates. Non-production tests do not authorize production.
Safe-state guidance
STATIC, EXPANDED SPECIMENS · NO CUSTOMER DATANormal conceptual docs
Read architecture; open approved API contracts for exact implementation.
API Reference / Integration Guides ↗
Missing technical source
Exact source not confirmed. Keep conceptual guidance; request the approved source before implementation.
Integration owner review ↗
Unavailable route
Do not infer capability from a missing route. Use the related approved docs or seek source review.
Related documentation ↗
Unknown contract / currentness
Treat exact semantics as unconfirmed. Verify approved documentation and release sources.
API owner / current source ↗
Unsupported Coverage
Do not imply production support. Check capability-specific Coverage and approved alternatives.
Coverage review ↗
Uncertain result
Transport is uncertain. Consult governed current state / reconciliation; never infer commit success.
Documented recovery ↗
Partial outcome
Review item/status references. Reconcile the documented partial outcome; do not guess compensation.
API / Bulk & Batch docs ↗
Restricted data
Do not display or transmit unnecessary sensitive context. Use safe approved correlation references.
Privacy / safe support guidance ↗
No-JS text fallback
Architecture, ordered sequences and route labels remain the intended reading path without interactive meaning.
Plain-text docs navigation ↗
The minus indicators above show expanded text specimens. Meaning is in the labels and guidance—not color, hover or motion. These are design affordances, not a live runtime.
When the exact source is unavailable, keep the boundary visible.
No guessed metadata, unsupported Coverage claim or customer-data exposure. Plain-text equivalents and documentation routes are the intended fallback. Static specimens do not implement runtime behavior, accessibility or analytics.
Direct answers. Clear boundaries.
How does ZoikoTax integrate with billing/BSS?
By connecting approved transaction, quote, commit and invoice context with supported fiscal determination, obligations and evidence. Billing retains offer, rating, orchestration and customer-facing workflows; exact integration behavior is governed by approved API and integration documentation.
What is quote vs commit?
Quote/preview is prospective evaluation. Commit binds an authoritative decision only under approved semantics and idempotency. Persistence, expiry, mutation, reversal, timing and financial finality remain contract-defined—not inferred from this sequence.
Does it replace my BSS?
No. ZoikoTax supports fiscal functions; it does not replace your full BSS/OSS or ERP. Billing owns invoice presentation and account workflows, ERP/GL remains the accounting system of record, and external e-invoicing workflows vary by Coverage.
How handle retries/duplicate requests?
Use duplicate-safe contract-defined idempotency and approved retry/backoff guidance. A timeout is transport uncertainty, not commit state. Consult documented current state or reconciliation and follow exact error and recovery contracts; never guess compensation.
Can it run alongside an existing tax engine?
Coexistence and non-impacting Shadow/parallel evaluation are possible where approved. Compare supported outcomes without production changes before governed cutover, investigate gaps and preserve incumbent authority. Agreement is not proof of legal correctness; availability remains capability-specific.
Where test before production?
Start with API Reference for authentication, environment and exact contracts, then use Sandbox where available and documented event/batch testing. Verify approved Shadow comparison and Coverage separately. Non-production results do not guarantee go-live readiness.
Start with the technical source of truth.
Open the approved contracts, choose the integration path, then verify capability readiness and assurance.
API Reference
Exact contracts, authentication, errors and versioning.
Integration Guides
Owned workflows, mappings and implementation sequence.
Sandbox
Non-production testing where available.
Need to discuss your billing scope, system ownership or coexistence plan? Book a contextual demo after reviewing the technical sources.
Documentation first. No instant activation, free trial or credential issuance is implied.