ZoikoTax
DEVELOPERS · INTEGRATIONS · ERP & GENERAL LEDGER

Connect fiscal outcomesto finance with controlledaccounting interfaces.

Bridge approved ZoikoTax fiscal outcomes into enterprise accounting andreconciliation workflows while preserving the ERP or general ledger as thefinance system of record.

Open API Reference↗
Explore Integration Guides↗
Open Sandbox↗
Governed fiscal outcomes. Enterprise-owned accounting controls.
Architecture guidance, not a posting contract

This page explains integration architecture and control patterns. Exact journal structures, posting behavior, mappings, authentication, versions andreconciliation APIs remain governed by approved technical documentation.

DIRECT ANSWER

What is an ERP & GLintegration?

A governed fiscal-to-finance accounting bridge connects supported ZoikoTax outcomes andevidence to enterprise finance interfaces, then connects related records for reconciliation andinvestigation.

It is not an ERP or ledger replacement, a universal journal schema, or accounting advice. A fiscal result is notautomatically a posting; your enterprise ERP/GL retains accounting authority and posting controls.

01 · SYSTEM BOUNDARIES

One connected workflow. Distinctresponsibilities.

Keep fiscal authority and accounting authority separate—even when the interfaces connect them.

ZOIKOTAX · FISCAL SCOPE
Supported outcomes and governed evidence
ENTERPRISE ERP / GL · FINANCE SCOPE
Accounting system of record and posting controls
RESPONSIBILITY OWNER
CONCEPTUAL HANDOFF ↓
BOUNDARY & TEXT EQUIVALENT
Source transaction / billing
SOURCE AUTHORITY
Originating transaction
↓
The source system owns the originating transaction or invoice. Preserve its identity, versionand record history when connecting downstream fiscal and finance records.
ZoikoTax
FISCAL AUTHORITY
Fiscal outcome + evidence
↓
ZoikoTax produces supported, governed fiscal outcomes and associated evidence. A fiscaloutcome establishes fiscal context within its supported scope; it does not authorize anaccounting posting.
Accounting bridge
INTERFACE BOUNDARY
Governed mapping + interface
↓
The bridge maps supported fiscal concepts to approved finance interfaces. Actual mappingis customer-owned or governed configuration, not a universal accounting schema.
Enterprise ERP / GL
ACCOUNTING AUTHORITY
Accounting record + controls
↓
The enterprise ERP or general ledger remains the accounting system of record. It ownsledger processing, record authority and posting controls under the customer's accountingprocess.
Reconciliation / evidence
SCOPED RELATIONSHIPS
Investigation + audit links
Defined record relationships connect source, fiscal and finance outcomes for investigationand audit. Evidence preserves context; a match does not establish legal or accountingcorrectness.
Conceptual swimlanes only. Handoff arrows describe flow and responsibility—not a guarantee of synchronous behavior, processing order or posting success.
02 · ACCOUNTING BRIDGE

Prepare the handoff. Preserve the controls.

Each stage has a purpose and a publication boundary. Exact interfaces come from approved technicaldocumentation, not from the diagram.

CONCEPTUAL FLOW · NOT A RUNTIME CONTRACT
01
Fiscal outcome
02
Mapping
03
Journal / export
preparation
04
Transfer
05
Ledger
processing
06
Reconciliation
01
Fiscal outcome
Identify eligible, supported fiscal output and its evidence context. Eligibility for an interface does not make the fiscal resultan accounting posting.
02
Mapping
Apply customer-owned or governed mapping configuration. Chart-of-accounts and finance-dimension treatment must beapproved for the enterprise context.
03
Journal / export preparation
Prepare only the approved finance interface. This page does not define entries, debits, credits, fields or an accountingtreatment.
04
Transfer
Use the source-controlled API, batch, file or event route only where documented and supported. Transport, authenticationand versions are contract-specific.
05
Ledger processing
The enterprise ERP/GL applies its own processing and posting controls. A transfer or acceptance signal is not evidence thatledger posting completed.
06
Reconciliation
Connect defined references and investigate governed variances. Status and variance semantics remain source-controlled;do not infer correctness from a match.
Context travels with the handoff

Keep approved entity, ledger, period, currency, mapping and currentness context visible at consequential handoffs. Do not assume that context or support isuniversal.

03 · INTERFACE PATTERNS

Choose the route your controls can govern.

These are conceptual uses, not a connector catalog or a promise of production availability. Publication and support remain governed for every route.

Journal interface
Connect supported fiscal concepts to an approved finance journal interface. The ERP/GL retains responsibility for the accounting record and posting controls.
Boundary: approved journal contract only
Accounting export
Prepare supported outcomes for a governed accounting handoff where an export is approved. No file format, entry structure or ERP permission is implied.
Boundary: approved export documentation
API integration
Use documented interfaces for the supported finance workflow. Exact fields, requests, responses, authentication and versions belong in the API Reference.
API Reference → /developers/api/
Bulk / batch
Route high-volume finance handoffs through Bulk & Batch where supported. Exact asynchronous submission, results and recovery are defined by that contract.
Bulk & Batch → /developers/bulk-batch/
Event-driven continuation
Continue a workflow from an approved notification where supported. Notification meaning, delivery and continuation behavior are not inferred here.
Webhooks & Events → /developers/webhooks-events/
Reconciliation import
Bring defined finance-side references or outcomes into a scoped reconciliation interface where approved. Imported records do not become accounting or legal proof.
Boundary: approved reconciliation contract
No accounting inference

Do not infer a journal schema, debit/credit treatment, account mapping, ledger write permission or posting behavior from a fiscal outcome or interface pattern. Actual accounting treatment follows approved documentation and the customer’s accounting process.

04 · MAPPING & DIMENSIONS

Finance dimensions are governed, not guessed.

Conceptual mapping categories — configuration and support remain governed. These categories are not aproduction schema and contain no actual account or ledger values.

Legal entity / company
Identify the enterprise scope for an approved handoff. Entity treatment is not automatically universal.
Governed enterprise context
Ledger / book
Identify the applicable accounting context under the enterprise’s own ledger authority.
ERP / GL-owned context
Account / chart of accounts
Use the customer’s approved chart-of-accounts mapping. No account numbers or default mappings are provided.
Customer / governed configuration
Cost center / business unit
Include this optional dimension only when approved and supported for the interface.
Optional · support-dependent
Tax / fee category
Map supported fiscal concepts using approved category definitions, not inferred accounting treatment.
Supported concepts only
Currency
Carry defined currency context. Neither support nor currency accounting treatment is implied.
Interface-specific context
Period
Carry approved period context without inventing posting windows, close rules or reopening behavior.
Customer accounting process
External correlation
Preserve safe, defined reference relationships across source, fiscal and finance handoffs.
Contract-defined relationships
EXPLICIT OWNERSHIP
Your accounting context.Approved mappingresponsibility.

The customer or designated governed configuration process owns actual finance mappings and theirapproval. ZoikoTax provides supported fiscal concepts and evidence within its scope. Interfacedocumentation defines what can be transferred; the enterprise ERP/GL owns how accounting records arecontrolled. Resolve missing ownership before a consequential handoff.

05 · ENTERPRISE SCOPE

Keep context visible at the decision boundary.

Entity, ledger and period context belong beside consequential handoffs—not hidden behind an inferred default.

ILLUSTRATIVE CONTEXT · NOT A SCHEMA
Before preparation.Before transfer. Beforereview.

Placeholders show the kinds of source-controlled context that may be needed. Theydo not describe a live ledger or imply postingauthority, available currencies or period rules.

Legal entity
[source-controlled entity context]
Ledger / book
[approved enterprise ledger context]
Accounting period
[source-controlled period context]
Currency
[defined currency context]
Mapping version
[approved mapping reference]
Approval / currentness
[source-confirmed control context]
Unknown context requires governed review

Do not guess a period, mapping version or approval state. Follow the authoritative interface documentation and the customer’s accounting process whencontext is absent or currentness cannot be confirmed.

06 · CORRECTIONS & REPROCESSING

Preserve the history. Govern the next action.

Changes must retain the originating record linkage and source version history. Correction guidance describesrouting and control—not accounting or statutory treatment.

Source transaction corrected
Preserve the link to the original record and its source history. Use the supported source-to-fiscal correction path; do not infer an accounting adjustment.
Route: source documentation + Integration Guides
Fiscal outcome changes
Retain relevant outcome versions and evidence references. Follow the authoritative fiscal and interface documentation for supported downstream behavior.
Route: approved fiscal / interface documentation
Invoice correction
Keep invoice and transaction relationships where defined. The customer’s accounting process determines treatment; this page does not prescribe entries.
Route: authoritative correction documentation
Journal reprocessing
Reprocess only when the approved interface and customer control process allow it. No automatic adjustment, replay behavior or ledger write is implied.
Boundary: only if explicitly approved
Period closed
Do not infer a reopening rule or a permitted posting window. Retain the period context and refer the unresolved instruction to the customer’s accounting process.
Boundary: never prescribe reopening
Duplicate / replay
Follow contract-defined correlation and replay semantics. A repeated request does not imply universal protection against duplicate ledger posting.
Route: API Reference + supported recovery contract
Unresolved or unknown → governed review

When correction instructions, period context or supported reprocessing behavior are unknown, preserve lineage and route the question for governed review. Do not silently adjust,overwrite history, reopen a period or infer statutory treatment.

07 · RECONCILIATION INTERFACES

Close the loop without inventing certainty.

Reconciliation is a first-class finance-control workflow: connect defined relationships, investigate governedvariances and retain historical evidence.

CONCEPTUAL RELATIONSHIPS · NOT LIVE RECORDS
Defined identities only • historical context retained
SOURCE ↔ FISCAL ↔ INVOICE
Transaction
Fiscal outcome
Invoice
Text equivalent: link the transaction, fiscal outcome and invoice through scoped identities and reference relationships only where the approved contracts define them.
FISCAL ↔ BRIDGE ↔ FINANCE
Fiscal outcome
Accounting bridge
Ledger outcome
Text equivalent: connect the fiscal outcome to its accounting bridge handoff and defined ledger outcome references. Keep enterprise accounting authority separate from the fiscalresult.
Defined relationship → governed variance → investigation route → historical evidence → scoped reconciliation review
↶ Return to the defined relationships with retained evidence for scoped review. No automatic closure or correctness is implied.
Match within defined scope
Use only approved identity and referencerelationships. A match is not legal oraccounting proof, and does not imply postingsuccess.
Scope and meaning are contract-defined
Investigate governed variance
Use source-controlled variance categories andinvestigation routes. Ambiguity remainsunresolved until governed review—not aninvented accuracy score.
No correctness inference
Retain historical evidence
Keep source lineage, relevant versions andprior evidence references for investigation.Preserve context across correction andreconciliation paths.
Evidence & Replay · where supported
Status words are not universal finance states

“Accepted”, “posted” and “rejected” have contract-specific meanings where defined. They are not live states on this page and must not be interpreted asequivalent across fiscal, transfer and ledger workflows.

08 · BATCH, ASYNC & RECOVERY

A finance handoff is not a posting receipt.

For high-volume interfaces, Bulk & Batch owns the exact asynchronous contract. Submission, status and resultsemantics must be read in their documented scope.

CONCEPTUAL ASYNC HANDOFF · EXACT CONTRACT IN BULK & BATCH
01
High-volume finance handoff
02
Asynchronous processing
03
Governed status / result
04
Reconciliation
Idempotency
Treat repeat handling as a conceptual control.Exact keys, scope and semantics are API-defined—not a universal duplicate-postingguarantee.
API-defined semantics
Retry
Retry only as the contract allows. This guidedoes not define schedules, counts, timing or apromise of eventual posting.
Contract-defined behavior
Partial failures
Use approved result lookup and recoverypaths. Keep unresolved portions visible; do notcollapse a partial result into “complete”.
Approved lookup / recovery
Validation errors
Read exact validation codes and their handlingin the API documentation. Do not deriveaccount treatment from a validation response.
API Reference is authoritative
Safe correlation
Preserve approved references acrosssubmission, result and reconciliation. Avoidexposing sensitive finance details indiagnostics.
Defined reference relationships
Replay / re-run
Use only explicitly supported behavior andapproved customer controls. No automaticledger adjustment or general replay permissionis implied.
Supported behavior only
Acceptance ≠ completed ledger posting

An accepted submission or transfer signal does not establish that ERP/GL processing or posting completed. Exact status meaning, result retrieval andrecovery belong to the approved contract.

Open Bulk & Batch↗
Open API Reference↗
09 · EVIDENCE & APPROVAL CONTROLS

Keep the context that makes review possible.

Evidence is a core finance-control capability, not a decorative trust statement. Lineage and pinned contextsupport investigation without implying a compliance certification.

Source provenance
Preserve originating record lineage and source history for investigation.
Relevant versions
Retain relevant rule, content and interface versions; pin context where the approved workflowdefines it.
Approval / control concepts
Use approved control requirements without inventing roles, permissions or an approvalhierarchy.
Correlation links
Connect defined references across source, fiscal outcome, finance transfer and reconciliation.
Historical replay route
Use Evidence & Replay where supported to revisit historical context through an authoritativeroute.
Audit export
Use an export only if a real, approved audit artifact exists. Do not infer an export format orcertification.
ILLUSTRATIVE EVIDENCE · NO CUSTOMER DATA
A trace you can investigate.

Conceptual categories only. No amounts, account IDs,journals, tax records, subscriber data or credentialsare shown.

↓
Source provenance
↓
Fiscal outcome + context
↓
Finance transfer references
↶
Reconciliation + history
Versions → relevant and source-confirmed
Approval context → where defined and approved
Replay / audit artifact → supported routes only
Traceability is not a certification

Historical evidence and correlation can support investigation and audit. They do not, by themselves, establish legal correctness, accounting correctness orcompliance certification. Trust remains separately authoritative for assurances.

10 · COEXISTENCE & MIGRATION

Modernize the bridge. Keep enterprise control.

Inventory and govern the interfaces you already operate. Coexistence does not require forced rip-and-replace,and readiness depends on the approved enterprise scope.

01
→
Discover
Inventory incumbent interfaces, responsibilities and finance owners.
02
→
Map
Confirm finance dimensions and approved mapping responsibility.
03
→
Connect non-
production
Use supported non-production interfaces with approved synthetic data.
04
→
Compare where
approved
Compare defined outcomes and investigate variance without production impact.
05
→
Reconcile
Trace defined source, fiscal and finance relationships and evidence.
06
→
Approve
Confirm customer readiness gates and the required governed approvals.
07
→
Cut over governed
Follow the approved cutover path; do not infer rollback or timing guarantees.
08
Operate
Keep controls, correlation and governed reconciliation in the operating workflow.
Shadow comparison must remain non-impacting until approval

Shadow Assurance, where approved and supported, must not change production outcomes before an approved cutover. Comparison agreement is not proofof accounting or legal correctness. Investigate variance and preserve evidence before approving any consequential transition.

GOVERNED READINESS, NOT A GUARANTEE

No zero-downtime, instant rollout or universal rollback promise is made. Use source-backed Shadow Assurance and integration guidance for the supported enterprise scope.

11 · SANDBOX & READINESS

Test the trace, not just the request.

Use approved non-production routes where available. Test end-to-end reconciliation relationships withapproved synthetic mapping data, not real customer finance records.

API request / response
Verify the exact supported request and response contract in the API Reference. Do not treat this architecture page as a schema.
API Reference · exact contract
Bulk asynchronous workflow
Test documented submission, status, result lookup and supported recovery behavior in the approved non-production scope.
Bulk & Batch · async contract
Event delivery
Verify approved notification meaning and delivery behavior. Do not assume a notification confirms finance posting.
Webhooks & Events · notification contract
Sandbox environment
Use Sandbox where available with approved synthetic mapping data. Availability and access remain separately governed.
Sandbox · non-production only
Reconciliation trace
Test defined relationships from originating records through fiscal outcomes, finance handoffs and historical evidence.
End-to-end · scoped references
Coverage verification
Check capability-specific support and readiness in Coverage. No country, currency or production availability is inferred here.
Coverage · separately authoritative
BEFORE A CONSEQUENTIAL HANDOFF
Readiness is a
governed review.

Illustrative review checklist—not completedapprovals or a live readiness assessment.

Enterprise finance and interface owner identified
Mapping responsibility and configuration approval confirmed
Defined correlation across source, fiscal and finance handoffs
Correction, retry and reconciliation behavior understood
Evidence references and required approvals verified
Production readiness and Coverage independently confirmed
A sandbox test is not a production entitlement

Successful non-production testing alone does not establish production access, supported coverage, accounting correctness or production readiness.Confirm the approved enterprise scope and Coverage independently.

Open Sandbox↗
Verify Coverage↗
13 · SAFE UI STATES

When detail is absent, keep the guide useful.

Illustrative documentation patterns only—not live operational states or customer ledger data. Explicit textcarries the meaning; color, hover and motion are never the only signal.

Conceptual guide
Default: explain the architecture andresponsibility boundaries. Keep technicalroutes and full text equivalents available besidethe graphics.
Illustrative default · not an active integration
Source / mapping not published
“Exact mapping is not published here.” Retainconceptual categories and refer to approveddocumentation and the mapping owner.
No invented fallback schema
Unavailable route
“This route is unavailable in the current scope.”Keep the surrounding guidance and refer toIntegration Guides; do not promise access.
Availability must be source-confirmed
Unknown period / correction
“Instruction requires governed review.”Preserve originating linkage and context; donot infer a posting, period reopening orstatutory treatment.
Review before a consequential action
Currentness unknown
“Currentness cannot be confirmed.” Useauthoritative source context before relying on amapping, version or approval instruction.
Do not silently assume current
Partial result
“Result is partial; unresolved portions remain.”Follow approved lookup and recovery guidancerather than implying completion or postingsuccess.
Exact result meaning is contract-defined
Ambiguous variance
“Variance requires investigation.” Retaindefined references and historical evidence; donot label an ambiguous comparison as correct.
No correctness inference
Restricted detail
“Detail is restricted in this view.” Show onlyapproved safe context and an authoritativereview route, not sensitive finance data.
No customer amounts or account records
Adjacent text fallback
Keep each architecture relationship andqualifier readable as adjacent text. The coredocumentation remains understandablewithout an interactive graphic.
No-JS reading pattern · illustrative
KEYBOARD FOCUS · ILLUSTRATIVE
Open API Reference↗
Visible focus boundary and a generous target. Theroute label remains explicit.
HOVER · ILLUSTRATIVE
Explore Integration Guides ↗
Underline reinforces the route; no required informationappears only on hover.
EXPANDED GUIDANCE · ILLUSTRATIVE
Where is the exact contract?−
API, Bulk & Batch and Events documentation remainauthoritative. The answer is visible here.
14 · FREQUENTLY ASKED QUESTIONS

Direct answers. Controlled finance boundaries.

The architecture stays useful without inventing the contracts it points to. All answers are shown for a clear,continuous reading path.

Does ZoikoTax replace myERP/GL?
No. ZoikoTax provides supported, governed fiscal outcomes and evidence. Your enterprise ERP or general ledgerremains the accounting system of record and owns posting controls. The integration is a bridge—not areplacement ledger or accounting advice.
How do fiscal outcomesconnect to accounting?
Through supported concepts, governed mapping and an approved finance interface. Preparation and transferremain distinct from enterprise ledger processing. A fiscal result is not automatically a posting; exact structuresand behavior belong in approved technical documentation.
How are journal mappingscontrolled?
Actual chart-of-accounts and finance-dimension mapping is customer-owned or governed configuration, withexplicit responsibility and approval. This guide shows conceptual categories, not account numbers, defaultmappings or a universal journal schema.
How does reconciliationwork?
Defined identities and reference relationships connect transaction, fiscal outcome and invoice, and connect fiscaloutcome, accounting bridge and ledger outcome. Governed variance categories, investigation routes andhistorical evidence support review. A match is not legal or accounting proof.
How are corrections handled?
Preserve originating record linkage and source version history, then follow authoritative correctiondocumentation and the customer’s accounting process. Reprocessing is permitted only where approved.Unknown instructions require governed review—not inferred entries, automatic adjustments or period reopening.
Can integration use batchprocessing?
Where supported and approved, high-volume finance handoffs can use Bulk & Batch. Its documentation owns theexact asynchronous contract, status, results and recovery behavior. Submission acceptance is not completedledger posting, and availability must be independently confirmed.
CONTROLLED INTEGRATION STARTS WITH THE CONTRACT

Connect the architecture. Keep the accountingauthority.

Open the approved technical documentation for your supported interface. Confirm mapping responsibility, enterprise controls andCoverage before a consequential handoff.

Open API Reference↗
Explore Integration Guides↗