ACF Connector Specification — e-conomic
1. Purpose
This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with Visma e-conomic.
e-conomic is treated as a source cloud accounting platform rather than as an import/export format.
The preferred ZAYAZ architecture uses:
- e-conomic OpenAPI as the primary integration surface;
- the older e-conomic REST API only where required functionality has not yet migrated to OpenAPI;
- e-conomic webhooks for near-real-time change detection;
- periodic authoritative synchronization to recover missed events; and
- TrustGate to preserve source, transformation and calculation lineage.
The connector enables authorized e-conomic data to participate safely in:
- ESG screening;
- emissions estimation;
- supplier classification;
- invoice and transaction analysis;
- project and department allocation;
- evidence collection;
- physical-activity discovery;
- reporting prepopulation;
- audit and assurance;
- supplier ESG workflows; and
- regulatory data-quality assessment.
The connector does not treat accounting information as environmental evidence merely because the data originates from e-conomic.
ACF determines:
- which accounting agreement granted access;
- which application role governs access;
- which e-conomic modules are enabled;
- which API surface provides each required field;
- what the source value can validly establish;
- whether additional evidence is needed;
- what ZAYAZ may derive from the source; and
- how the resulting ESG information remains traceable.
2. Connector model
e-conomic is an OpenAPI-first, webhook-capable cloud accounting connector.
The recommended architecture is:
e-CONOMIC
│
┌────────────┴────────── ──┐
│ │
OpenAPI WEBHOOKS
│ │
authoritative records change signal
│ │
├── Legacy REST fallback │
│ │
└────────────┬────────────┘
▼
ZAYAZ API HUB
│
agreement profile
│
▼
TRUSTGATE
│
▼
ACF
┌────────────┼────────────┐
│ │ │
normalize validate classify
│ │ │
└────────────┼────────────┘
▼
CANONICAL DATA MODEL
│
┌────────────┼────────────┐
▼ ▼ ▼
MICE FOGE ZARA
│
▼
GOVERNED ESG DATA
3. OpenAPI-first architecture
e-conomic provides two RESTful API families:
OpenAPI
│
└── actively developed
Legacy REST
│
└── stable / feature frozen
ZAYAZ should therefore implement:
OpenAPI first, legacy REST only when required.
This is not merely a developer preference.
It is an architectural migration policy.
Any new ZAYAZ e-conomic capability should first determine whether an appropriate OpenAPI resource exists.
4. Legacy REST fallback
Some source functionality may still exist only in the older REST API.
In such cases ACF may use legacy REST.
The fallback sequence is:
required source capability
↓
available in OpenAPI?
│
┌──┴──┐
yes no
│ │
OpenAPI legacy REST?
│
┌──┴──┐
yes no
│ │
use + enrichment /
register unresolved
fallback
Every legacy dependency should be removable independently when OpenAPI reaches equivalent capability.
5. Resource-specific API versions
e-conomic's OpenAPI is composed of versioned resource APIs.
Examples include:
Accounting Years API
Accounts API
Booked Entries API
Budgets API
Customers API
Dimensions API
Documents API
Journals API
Products API
Projects API
Quote to Cash API
Subscriptions API
Suppliers API
Webhooks API
Versions use a three-part convention:
major.minor.patch
ACF must therefore record versions per API family, not merely:
e-conomic API version = X
because no single version necessarily represents all e-conomic APIs.
6. Authentication model
e-conomic uses a two-token authorization model.
Each request combines:
X-AppSecretToken
+
X-AgreementGrantToken
The first identifies the application.
The second represents the accounting agreement that granted the application access.
This is a particularly clean multi-tenant source identity model.
7. AppSecretToken
The AppSecretToken belongs to the ZAYAZ integration application.
It must be treated as a high-sensitivity application secret.
It may not appear in:
- logs;
- telemetry;
- source lineage;
- TrustGate payloads;
- error messages;
- browser-visible diagnostics; or
- exported evidence packages.
It belongs only in the approved secrets infrastructure.
8. AgreementGrantToken
The AgreementGrantToken represents permission to access a particular accounting agreement.
Conceptually:
ZAYAZ application
│
▼
AppSecretToken
Customer agreement
│
▼
AgreementGrantToken
│
└──────────┐
▼
API authorization
The AgreementGrantToken is therefore not merely a generic credential.
It is part of the source-tenant boundary.
9. Installation flow
A customer authorizes the ZAYAZ app through e-conomic's installation flow.
The normal process is:
ZAYAZ installation URL
↓
customer logs into e-conomic
↓
customer grants access
↓
AgreementGrantToken created
↓
redirect to ZAYAZ
↓
connection registered
ZAYAZ can automate receipt of the grant token through an approved redirect URL.
10. Accounting-agreement identity
An e-conomic source connection must resolve to:
e-conomic accounting agreement
+
ZAYAZ tenant
+
ZAYAZ organization
+
E-C-O Number
before any source record enters canonical processing.
A company name is not sufficient source identity.
11. Application roles
e-conomic controls API data access using application roles.
Documented roles include:
- SuperUser;
- Bookkeeping;
- Sales; and
- Project Employee.
Different resources are accessible under different roles.
Therefore:
API endpoint exists
does not necessarily mean:
ZAYAZ application may access endpoint
The effective application role must be part of the connector profile.
12. Module-aware capability
Some e-conomic information also depends on customer modules.
Examples include:
- projects;
- dimensions;
- departments;
- time-related functionality; and
- subscriptions.
Therefore effective capability is:
API resource
+
API version
+
application role
+
customer module
+
customer agreement
=
effective capability
This should become a standard ACF capability-resolution model.
13. Customer connector profile
Each activated agreement generates:
ACF-ECONOMIC-CUSTOMER-PROFILE
The profile records:
- accounting-agreement identity;
- application role;
- available modules;
- OpenAPI resource families;
- active API versions;
- legacy REST fallbacks;
- webhook event types;
- dimension capability;
- project capability;
- document capability;
- canonical mappings;
- data-quality capability; and
- TrustGate registration.
14. Test environments
e-conomic supports demo and trial agreements for integration testing.
ZAYAZ should use these before customer production activation.
The development path is:
demo / trial agreement
↓
authentication
↓
API discovery
↓
mapping
↓
webhook testing
↓
lineage testing
↓
production preflight
Demo API access must not be treated as evidence that a production agreement exposes identical modules or permissions.
15. Accounting years
e-conomic exposes accounting years and accounting periods.
These are critical context for financial source data.
ACF preserves:
- accounting year;
- accounting period;
- closed/open state where available;
- entry dates; and
- source-year relationships.
A financial year may span more than a simple January–December calendar year.
16. Accounting years are not ESG reporting periods
An important boundary is:
e-conomic accounting year
is not necessarily:
ZAYAZ sustainability reporting period
The two may coincide.
But they remain separate governed concepts.
ZAYAZ maps source accounting dates into the applicable ESG reporting period.
17. Accounts
Accounts provide valuable classification signals.
For example:
Account
+
Supplier
+
Entry text
+
Project
+
Department
↓
ESG classification
is stronger than:
Account
↓
ESG classification
Account number alone must not determine environmental meaning.
18. Booked entries
Booked Entries are especially important to the connector.
They provide the posted accounting reality of the e-conomic agreement.
Relevant information can include:
- amount;
- amount in base currency;
- currency;
- date;
- due date;
- entry type;
- customer;
- supplier;
- supplier invoice number;
- project;
- voucher;
- entry text;
- quantities;
- units; and
- departmental distribution.
This is a strong source for ESG transaction analysis.
19. Booked entries versus invoices
An invoice represents a business document.
A booked entry represents accounting recognition.
These objects may be related but must not be collapsed.
For example:
Supplier invoice
↓
Accounting booking
↓
Booked entries
The document and accounting representation can play different roles in ESG evidence.
20. Supplier invoices
Supplier invoice information is highly valuable for ESG.
It may contribute:
- supplier identity;
- invoice number;
- currency;
- due date;
- financial amount;
- account classification;
- project relationship;
- quantity;
- unit;
- department allocation; and
- source document evidence.
This can move an analysis substantially beyond generic ledger screening.
21. Supplier payments
Supplier payment entries can help reconcile:
supplier invoice
↓
open payable
↓
payment
↓
matched financial state
Payment status does not normally alter the environmental occurrence represented by the purchase, but it can strengthen financial reconciliation.
22. Customer invoices
Customer invoices can contribute to:
- product and service analysis;
- customer-project attribution;
- revenue denominators;
- emissions-intensity calculations;
- downstream activity analysis; and
- evidence reconciliation.
Sales activity must remain directionally distinct from purchased-goods activity.
23. Invoice lines
Invoice-line detail can substantially improve classification.
For example:
Invoice:
DKK 95,000
contains less environmental information than:
Line 1: Product A — quantity 40
Line 2: Delivery — quantity 1
Line 3: Installation — 12 hours
when such structured information exists.
Line structure should therefore be preserved in canonical mapping.
24. Products
Products provide reusable business semantics across sales documents.
Potential ESG uses include:
- product classification;
- service classification;
- quantity interpretation;
- product-footprint lookup;
- emissions-intensity calculation;
- sales allocation; and
- downstream analysis.
A product number is a source business identifier.
It becomes an ESG category only through governed mapping.
25. Projects
Projects are a particularly useful allocation dimension.
Potential uses include:
- construction emissions;
- consulting-project footprint;
- project travel;
- project procurement;
- client engagement footprint;
- project revenue versus emissions; and
- project-level sustainability reporting.
The e-conomic project number must map to a canonical ZAYAZ project identity.
26. Time entries
Where the relevant Project functionality is enabled, time-entry information can add operational context.
This may support:
- employee-time allocation;
- project cost allocation;
- consulting-service footprints;
- project activity analysis; and
- intensity metrics.
Working hours are not automatically an emissions activity.
They become environmental inputs only where a governed method calls for them.
27. Departments
Department information can support organizational allocation.
For example:
e-conomic department 5
↓
semantic mapping
↓
ZAYAZ business unit
↓
E-C-O scoped organization context
The mapping must be explicit and versioned.
28. Departmental distributions
A transaction may be distributed across departments.
This creates a useful source for allocating shared expenditure.
Example:
Energy invoice DKK 100,000
│
├── 60% Department A
└── 40% Department B
If the e-conomic departmental distribution represents the intended organizational allocation, ZAYAZ can preserve and use it.
The distribution remains an accounting allocation unless separately validated as an environmental allocation.
29. Dimensions
e-conomic dimensions are especially interesting for ACF.
Dimensions can carry customer-defined accounting semantics.
That means their value is potentially high—but their meaning cannot be assumed.
A dimension may represent:
- department;
- location;
- product;
- activity;
- business unit;
- contract;
- customer category;
- quantity measure; or
- another customer-specific construct.
30. Dimension quantities
Booked entries can expose values such as:
quantity1
quantity2
together with associated units.
This creates a potentially powerful ESG bridge.
For example, a customer may have configured:
quantity1 = 12,450
unit1 = kWh
If that semantic relationship is validated, the source may provide actual physical activity.
But another customer could have:
quantity1 = 12,450
unit1 = hours
or another internal unit.
Therefore the number cannot be interpreted independently.
31. Semantic Activity Resolution
ACF should introduce a reusable pattern here:
SOURCE QUANTITY
│
▼
SOURCE UNIT
│
▼
SEMANTIC MAPPING
│
▼
ACTIVITY TYPE
│
▼
METHOD COMPATIBILITY
│
▼
EMISSION FACTOR
Only after this chain succeeds does the source become valid DQ3 activity data.
This pattern should apply beyond e-conomic.
32. Example — electricity
Suppose e-conomic returns:
supplier: Utility A/S
account: Electricity
quantity1: 8500
unit1: kWh
project: Copenhagen Office
After semantic validation:
8,500 kWh electricity
↓
Copenhagen office
↓
Denmark
↓
applicable electricity methodology
↓
factor resolution
↓
MICE calculation
This is materially better than spend-based estimation.
33. Example — unsafe interpretation
Suppose instead:
quantity1: 8500
unit1: UNIT-03
with no registered mapping.
ZAYAZ must not infer:
8,500 kWh
even if the account description says “Electricity.”
The correct state is:
candidate activity
↓
unit semantics unresolved
↓
enrichment / mapping required
34. Journals
The Journals API represents draft bookkeeping workflows before entries are finally booked.
This allows ZAYAZ to distinguish:
draft accounting state
from:
booked accounting state
For ESG reporting and audit evidence, booked source data should generally carry greater accounting authority than unbooked draft entries.
35. Draft versus booked state
ACF must preserve lifecycle state.
For example:
draft journal entry
↓
posted
↓
booked entry
An ESG result generated from draft data should remain distinguishable from a result generated from final booked accounting.
This becomes particularly important for continuous ESG dashboards.
36. Budgets
e-conomic exposes budget information through OpenAPI.
Budgets can support:
- planned-versus-actual ESG analysis;
- emissions forecasting;
- financial denominator forecasting;
- project forecasting;
- transition-plan financial modeling; and
- future activity estimation.
Budget figures must never be mixed silently with actual accounting values.
37. Budget lineage
Budget-derived ESG estimates should explicitly record:
source_type = budget
rather than:
source_type = actual
This allows FIRM, MICE and reporting engines to distinguish forecasts from historical performance.
38. Attached documents
e-conomic supports attaching documents to booked or draft entries.
Supported source evidence can include PDF and common image formats.
The linkage uses accounting-year and voucher context.
This is highly valuable for TrustGate.
39. Document evidence chain
An ESG result can therefore resolve through:
ESG datapoint
↓
MICE result
↓
classified activity
↓
booked entry
↓
voucher
↓
attached document
This is an auditor-friendly evidence chain.
The attached document does not automatically validate environmental interpretation, but it allows that interpretation to be inspected.
40. Document enrichment
If a booked entry only provides:
DKK 46,500
supplier: Energy A/S
the linked invoice document may contain:
Consumption: 14,250 kWh
Period: January
Meter: 123456
The accounting record can therefore act as the locator for higher-quality evidence.
This is one of the most important roles of ACF.
41. Webhooks
e-conomic provides a dedicated Webhooks API.
Webhook subscriptions can be created and managed programmatically.
Supported event types can also be discovered through the API.
ACF should therefore avoid maintaining a permanently hard-coded assumption about event coverage.
42. Dynamic event discovery
The connector activation process should query the current event-type catalogue.
Conceptually:
Webhooks API
↓
EventTypes
↓
supported source events
↓
ACF customer profile
↓
subscriptions
This makes the connector forward-adaptable.
43. Webhook bursts
e-conomic can send large numbers of webhook calls in rapid succession.
A bulk change may trigger many individual webhook requests rather than one aggregated event.
Therefore:
Webhook handlers must enqueue, not process.
The HTTP path should accept and durably queue the event.
Business logic runs asynchronously after receipt.
44. Webhook retry behavior
Failed webhook requests are retried.
The documented retry sequence progresses through several delays before the event is ultimately marked failed.
This means ZAYAZ should expect:
- repeated delivery;
- delayed delivery; and
- eventual permanent failure.
Processing must therefore be idempotent.
45. Webhook disablement
A particularly important e-conomic behavior is that a webhook can be disabled after excessive recent failures.
While disabled:
events are not queued for later delivery.
This means a disabled webhook can create a permanent source gap.
DaVE must treat disabled subscription state as a data-integrity incident rather than merely a connectivity issue.
46. Nightly reconciliation
e-conomic explicitly recommends periodic synchronization because webhooks alone cannot guarantee complete consistency.
The production pattern is therefore:
INITIAL SYNC
↓
WEBHOOK CHANGES
↓
API REREADS
↓
NIGHTLY RECONCILIATION
This should now be regarded as a core ACF pattern.
47. Manual reconciliation
The platform should also support an explicit:
Run source reconciliation
operation.
This is useful after:
- webhook outage;
- changed credentials;
- integration reactivation;
- mapping change;
- suspicious variance; or
- auditor challenge.
The result becomes a governed reconciliation event.
48. API fair use
e-conomic applies a fair-use policy per accounting agreement.
This reinforces the need for:
- webhooks;
- filtered queries;
- sensible pagination;
- local source identity caches;
- delta synchronization; and
- scheduled reconciliation rather than continuous brute-force polling.
API Hub should track consumption at agreement level.
49. Agreement-scoped API budgets
The architecture should be:
Agreement A
↓
API budget A
Agreement B
↓
API budget B
Agreement C
↓
API budget C
This allows ZAYAZ to detect inefficient connector behavior per customer.
A runaway synchronization should not remain invisible until the provider restricts the integration.
50. Source filtering
e-conomic APIs provide filtering on collection resources.
ACF should use source-side filters wherever supported.
Instead of:
retrieve 100,000 records
↓
discard 99,000
prefer:
filtered source query
↓
retrieve required records
This reduces API load and unnecessary data ingestion.
51. Pagination
Different e-conomic API families can expose different pagination patterns.
The connector must therefore treat pagination as part of the source API contract rather than implement one universal fixed algorithm.
The active pagination strategy belongs in the customer/API resource profile.
52. Currency
e-conomic booked entries can carry transaction currency and base-currency values.
This is highly useful for ESG spend calculations.
ACF preserves:
source amount
source currency
amount in base currency
separately.
If ZAYAZ performs another currency normalization for emission-factor purposes, that is an additional transformation.
53. Currency lineage
A spend calculation should therefore show:
Original:
DKK 50,000
Accounting base:
DKK 50,000
Factor reference:
EUR 6,700 equivalent
Calculation:
EUR-normalized spend × factor
The original accounting value remains unchanged.
54. Supplier identity
e-conomic supplier master data is strategically valuable.
It can support:
- supplier spend aggregation;
- supplier-country enrichment;
- supplier questionnaires;
- due-diligence workflows;
- Scope 3 analysis;
- supplier-specific factor resolution;
- primary-data requests; and
- evidence routing.
Supplier identity alone is not supplier-specific environmental data.
55. Customer identity
Customer records can support:
- downstream analysis;
- project association;
- product/service revenue allocation;
- client-specific emissions intensity; and
- customer-facing sustainability reporting.
Customer personal/contact details should not be ingested unless required for the approved purpose.
56. Data minimization
The connector should retrieve only what is needed.
For example:
Needed:
supplier ID
invoice amount
currency
account
project
quantity
unit
does not automatically justify retrieving:
all customer contacts
all delivery contacts
all employee details
Source-side minimization is a privacy and efficiency control.
57. ESG processing model
The source-to-result chain is:
e-conomic source
↓
ACF registration
↓
canonical mapping
↓
normalization
↓
classification
↓
activity resolution
↓
method selection
↓
factor resolution
↓
MICE
↓
TrustGate
↓
governed ESG result
e-conomic tells ZAYAZ:
What financial or business event was recorded?
ZAYAZ determines:
What sustainability meaning can validly be derived from that record?
58. Spend-based emissions
A spend-based calculation may combine:
Account
+
Supplier
+
Booked entry
+
Supplier invoice
+
Project
+
Department
+
Text
↓
classification
↓
spend category
↓
currency normalization
↓
factor resolution
↓
tCO2e
This is stronger than account-only mapping.
59. Activity-based emissions
Where e-conomic contains a valid physical quantity and unit, a calculation may move beyond spend.
For example:
Booked Entry
│
quantity1 = 450
unit1 = litres
│
▼
validated activity
│
▼
fuel classification
│
▼
emission factor
│
▼
tCO2e
This is only valid once the unit and activity meaning have been confirmed.
60. Data-quality hierarchy
ACF applies the common five-level accounting data-quality hierarchy.
ACF-DQ1 — Accounting-only estimate
Typical inputs:
- account;
- booked entry;
- supplier;
- amount;
- entry text.
Typical use:
- screening;
- materiality;
- spend-based estimation.
ACF-DQ2 — Invoice-level data
Typical inputs:
- supplier invoice;
- sales invoice;
- line detail;
- product;
- linked document.
This often provides better classification.
ACF-DQ3 — Activity data
A valid physical quantity and unit exist.
These may come from:
- invoice lines;
- semantically validated dimensions;
- project data;
- linked documents;
- meter data; or
- other primary evidence.
ACF-DQ4 — Supplier-specific data
The data is attributable to the actual supplier, product, service or relationship.
ACF-DQ5 — Verified primary data
Primary data has undergone the required validation or independent verification.
61. Quality upgrade example
An e-conomic record might initially produce:
DQ1
DKK 75,000 electricity spend
Later an attached document produces:
DQ3
22,800 kWh electricity
Later supplier-specific evidence provides:
DQ4
contract-specific electricity characteristics
and assurance could produce:
DQ5
verified primary result
Each stage remains traceable.
62. Classification
Classification can use:
- account;
- booked-entry type;
- supplier;
- customer;
- invoice;
- invoice line;
- product;
- project;
- department;
- dimension;
- unit; and
- text.
The classification is a ZAYAZ-derived object.
It must never be presented as an e-conomic classification unless e-conomic supplied the same meaning explicitly.
63. Evidence linkage
e-conomic gives ZAYAZ strong accounting evidence relationships.
A value might resolve as:
VSME / ESRS datapoint
↓
ZAYAZ calculated result
↓
MICE execution
↓
classified source activity
↓
booked entry
↓
voucher
↓
attached invoice
↓
supplier
This enables an auditor to move from reported result to original accounting evidence.
64. FOGE prepopulation
FOGE can use validated e-conomic-derived data where the reporting requirement permits it.
Example:
booked entry
↓
invoice evidence
↓
physical activity
↓
MICE calculation
↓
requirement check
↓
FOGE prepopulation
But:
data available
does not automatically mean:
disclosure requirement satisfied
65. VSME and ESRS
e-conomic may contribute underlying information for:
- emissions;
- energy screening;
- procurement;
- supplier analysis;
- financial denominators;
- project allocation;
- expenditure-based metrics;
- revenue-based metrics; and
- evidence linkage.
It cannot independently establish complete disclosures concerning:
- sustainability policies;
- governance;
- due diligence;
- workforce practices;
- transition plans;
- targets;
- biodiversity;
- stakeholder engagement; or
- narrative explanations.
66. ZARA behavior
ZARA can use the customer connector profile to explain:
- which API supplied a source field;
- why legacy REST was required;
- whether a role restriction applies;
- whether a module is missing;
- what an accounting dimension means;
- whether a quantity qualifies as activity data;
- which accounting document supports a value;
- why enrichment is required;
- what data-quality tier applies; and
- whether the value is e-conomic-native or ZAYAZ-derived.
67. FOGE behavior
FOGE uses:
- source capability;
- field availability;
- evidence quality;
- source authority;
- module state;
- dimension semantics;
- reporting requirements; and
- enrichment state.
If the required evidence is missing, FOGE requests it.
It does not manufacture regulatory completeness.
68. MICE behavior
MICE receives governed calculation inputs.
A calculation should identify:
- accounting agreement;
- source record;
- accounting year;
- source amount or activity;
- source currency;
- source unit;
- semantic activity;
- project/department context;
- classification;
- method;
- factor;
- factor version;
- reporting period;
- data-quality tier; and
- provenance.
This allows deterministic reproduction.
69. COSE behavior
COSE compares available evidence against the relevant methodological or regulatory requirement.
For example:
Requirement:
validated electricity consumption
Available:
supplier invoice amount only
Result:
activity data missing
If instead:
quantity1 = 18,400
unit1 = kWh
semantic mapping = validated
then COSE may determine that the source satisfies the required activity input.
70. DaVE behavior
DaVE monitors both technical and semantic health.
Signals include:
- grant-token failure;
- revoked agreement access;
- API version drift;
- role change;
- module loss;
- webhook failure;
- webhook disablement;
- reconciliation mismatch;
- fair-use pressure;
- missing accounting year;
- unresolved dimension semantics;
- unknown unit;
- supplier-resolution failure; and
- unexpected variance.
A technically reachable API can therefore still be degraded for ESG purposes.
71. TrustGate behavior
TrustGate preserves:
e-conomic
↓
OpenAPI / REST / webhook
↓
source registration
↓
canonical mapping
↓
semantic dimension mapping
↓
classification
↓
calculation
↓
reporting
↓
verification
The lineage survives:
- recalculation;
- invoice correction;
- late entry;
- reclassification;
- project remapping;
- unit remapping;
- factor change;
- higher-quality evidence;
- manual override; and
- assurance review.
72. Historical changes
Accounting information may change after initial ingestion.
Examples include:
- late bookings;
- corrected entries;
- invoice changes;
- payments;
- matching changes;
- project changes; and
- period adjustments.
When material source data changes:
e-conomic mutation
↓
webhook / reconciliation
↓
DaVE detection
↓
TrustGate lineage event
↓
affected ESG result
↓
revalidation
↓
recalculation if required
Prior results remain auditable.
73. Closed accounting years
Accounting-year state is a useful control signal.
A change affecting a previously closed period deserves increased scrutiny.
However:
accounting year closed
does not necessarily mean:
ESG reporting period locked
The two lifecycles remain separately governed.
74. Budget versus actual
The connector must explicitly distinguish:
ACTUAL
from:
BUDGET
This allows ZAYAZ to support both:
- historical ESG accounting; and
- sustainability forecasting.
FIRM can use budget-derived data without contaminating actual reported results.
75. Accounting-partner opportunity
e-conomic's accounting-agreement model is strategically important.
An accounting firm may manage multiple customers:
Accounting firm
│
├── Agreement A
├── Agreement B
├── Agreement C
└── Agreement D
│
▼
ZAYAZ ACF
│
isolated contexts
│
┌───────┼───────┐
▼ ▼ ▼
E-C-O A E-C-O B E-C-O C
This maps naturally to ZAYAZ's accounting-partner and white-label model.
76. Partner API opportunity
e-conomic also provides a separate Partner API which can assist with managing app/accounting-agreement relationships.
This should remain separate from the accounting-data connector itself.
Conceptually:
Partner API
↓
connection administration
Accounting APIs
↓
customer accounting data
Keeping these planes separate is architecturally desirable.
77. Potential continuous sustainability bookkeeping
The combination of:
- booked entries;
- invoices;
- supplier identity;
- projects;
- dimensions;
- physical quantity fields;
- documents;
- webhooks; and
- nightly reconciliation
creates a foundation for continuous sustainability bookkeeping.
Instead of sustainability reporting beginning months after year-end:
accounting transaction
↓
near-real-time ACF ingestion
↓
classification
↓
quality assessment
↓
calculation / evidence gap
↓
continuous ESG ledger
This is one of the strategic purposes of ACF.
78. Source authority ladder
Not all e-conomic objects have equal authority.
A useful default hierarchy is:
Draft journal
↓
Booked entry
↓
Booked entry + linked invoice
↓
Booked entry + validated physical activity
↓
Supplier-specific evidence
↓
Verified primary evidence
The exact authority depends on the calculation purpose.
79. Recommended production architecture
The preferred production deployment is:
e-CONOMIC
│
┌────────────┴────────────┐
│ │
OpenAPI Webhooks
│ │
primary API change events
│ │
Legacy REST │
fallback │
│ │
└────────────┬────────────┘
▼
ZAYAZ API HUB
│
agreement capability
+ API profile
│
▼
TRUSTGATE
│
source lineage
│
▼
ACF
┌────────────┼────────────┐
│ │ │
normalize validate classify
│ │ │
└────────────┼────────────┘
▼
CANONICAL DATA MODEL
│
┌────────────┼────────────┐
▼ ▼ ▼
MICE FOGE ZARA
│ │ │
└────────────┼────────────┘
▼
GOVERNED ESG OUTPUT
A nightly reconciliation process operates alongside the webhook path.
80. Quick-start implementation
A controlled pilot should:
- create a test or demo accounting agreement;
- create the ZAYAZ e-conomic application;
- configure the appropriate application role;
- generate the AppSecretToken;
- authorize the test agreement;
- capture the AgreementGrantToken;
- resolve agreement identity;
- inspect available OpenAPI resources;
- identify required legacy REST fallbacks;
- generate the customer connector profile;
- ingest a limited accounting period;
- map accounts, suppliers, products, projects and dimensions;
- inspect quantity and unit semantics;
- perform initial ESG screening;
- test document evidence retrieval;
- configure webhooks;
- test webhook failure/retry behavior;
- perform reconciliation; and
- verify TrustGate lineage.
81. Production implementation
Production should add:
- secure dual-token handling;
- automated grant redirect;
- accounting-agreement mapping;
- role and module capability discovery;
- version-pinned OpenAPI clients;
- legacy REST fallback routing;
- source filtering;
- fair-use monitoring;
- durable webhook queues;
- webhook subscription monitoring;
- nightly reconciliation;
- document evidence registration;
- dimension semantic mappings;
- accounting-year controls;
- TrustGate registration;
- DaVE monitoring; and
- governed recalculation.
82. Dimension-enriched implementation
Where customers use e-conomic Dimensions meaningfully, the connector can add a higher-value processing layer.
For example:
e-conomic quantity
+
e-conomic unit
+
project
+
department
↓
ZAYAZ semantic mapping
↓
activity type
↓
physical activity
↓
MICE
This should be optional because customers may configure dimensions differently.
83. Hybrid ESG implementation
The strongest result will often combine e-conomic with external sources.
For example:
e-conomic
│
├── supplier
├── invoice
├── booked entry
├── quantity
└── project
+
attached invoice
+
supplier portal
+
meter data
+
approved factor
↓
governed ESG result
ACF orchestrates the accounting foundation while allowing better evidence to supersede weaker estimates.
84. Limitations
The connector has several material limitations.
84.1 OpenAPI coverage is evolving
Some functionality may still require legacy REST.
84.2 Application roles restrict visibility
API availability must not be confused with configured application access.
84.3 Modules affect capability
Projects and dimensions may not be available for every agreement.
84.4 Webhooks can permanently miss events
Disabled webhooks do not retain all events for future replay.
84.5 Webhooks can arrive in bursts
Durable queueing is required.
84.6 Fair-use constraints require efficient synchronization
Repeated full-source polling is inappropriate.
84.7 Dimensions are customer-defined
Their environmental meaning must be governed.
84.8 Quantity does not automatically equal ESG activity
Unit and business semantics must be validated.
84.9 Accounting documents are not complete ESG evidence
Additional primary evidence may be necessary.
84.10 Accounting data cannot satisfy every sustainability disclosure
Policies, governance, workforce and narrative requirements generally require other sources.
85. Connector activation gate
A production e-conomic connector should not activate until:
AppSecretToken PASS
AgreementGrantToken PASS
Accounting-agreement identity PASS
ZAYAZ organization mapping PASS
E-C-O Number mapping PASS
Application role PASS
Module capability PASS
OpenAPI profile PASS
Legacy REST fallbacks PASS / N/A
Accounting-year context PASS
Canonical mapping PASS
TrustGate registration PASS
Initial reconciliation PASS
Fair-use controls PASS
Monitoring PASS
For webhook-enabled production profiles:
Event-type discovery PASS
Subscription creation PASS
Durable queue PASS
Retry handling PASS
Disablement detection PASS
Nightly reconciliation PASS
must also succeed.
86. Definition of done
The e-conomic connector is production-ready when ZAYAZ can demonstrate that it can:
- authenticate using AppSecretToken and AgreementGrantToken;
- resolve the correct accounting agreement;
- map the agreement to the correct ZAYAZ organization and E-C-O Number;
- determine effective application role;
- determine relevant module capability;
- select OpenAPI as the preferred source surface;
- route explicitly governed gaps to legacy REST;
- pin and track resource-specific API versions;
- retrieve required accounting objects;
- preserve native e-conomic identifiers and relationships;
- resolve accounting-year context;
- retrieve booked entries correctly;
- preserve transaction currency and base-currency values;
- retrieve supplier and customer relationships;
- map products, projects and departments;
- discover dimension quantities and units;
- reject unresolved dimension semantics as activity data;
- promote validated quantities to activity candidates;
- retrieve and link source documents;
- create and manage webhook subscriptions;
- process webhook bursts safely;
- tolerate retries and duplicate processing;
- detect webhook disablement;
- recover missed events through reconciliation;
- remain within the e-conomic fair-use policy;
- map source data into the ZAYAZ canonical model;
- normalize and validate it deterministically;
- detect source/API contract drift;
- detect relevant historical accounting mutations;
- execute ESG screening without inventing missing activity;
- upgrade calculations when higher-quality evidence becomes available;
- preserve prior calculations and provenance;
- support ZARA, FOGE, MICE, COSE, DaVE and TrustGate consumers;
- prevent cross-agreement and cross-tenant data leakage; and
- reproduce any material ESG result from original source to final output.
87. Source references
This connector specification is based primarily on current official Visma e-conomic material covering:
- e-conomic Developer Network;
- token-based API authentication;
- application roles;
- agreement authorization;
- OpenAPI;
- legacy REST;
- accounting years;
- accounts;
- booked entries;
- budgets;
- customers;
- suppliers;
- dimensions;
- documents;
- journals;
- products;
- projects;
- Quote to Cash;
- subscriptions;
- webhooks;
- filtering and pagination;
- fair-use requirements; and
- app-partner integration requirements.
The current e-conomic API contracts remain authoritative for resource- and field-level implementation.
The ACF customer connector profile must be reviewed or regenerated when material changes affect:
- OpenAPI resource versions;
- legacy REST dependencies;
- application roles;
- accounting-agreement access;
- enabled modules;
- webhook event types;
- accounting-year configuration;
- project configuration;
- dimensions;
- source documents;
- canonical mappings; or
- integration authorization.
Runtime Provider Extension
The provider-specific runtime contract for this connector is maintained separately from the common ACF connector frontmatter.
It contains machine-actionable provider semantics that are intentionally not part of the common ACF schema, including authentication lifecycle, provider object revision semantics, change-capture constraints and provider-specific capability rules.
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-ECONOMIC
provider:
namespace: visma.economic
name: Visma
product: e-conomic
runtime:
source_contract:
modern_openapi_preferred: true
stable_rest_fallback_supported: true
source_identity:
agreement_context_required: true
capability_rules:
effective_capability_depends_on_modules_and_roles: true
partner_api_supported: true
change_capture:
webhook:
supported: true
may_be_disabled_by_provider: true
gap_recovery_required: true
reconciliation:
required: true
recommended_frequency: nightly
source_semantics:
booked_entries_quantity:
activity_status: candidate
maximum_quality_after_semantic_validation: ACF-DQ3
requires_business_semantic_resolution: true
department:
candidate_id_class: EBU
automatic_resolution_allowed: false
project:
candidate_id_class: EBP
automatic_resolution_allowed: false
evidence:
documents_api_supported: true
extensions:
authorization:
application_role_and_customer_module_may_gate_resources: true
governance:
status: active
last_verified: 2026-08-30
review_interval_days: 90
change_control_required: true
source_basis: connector_specification