ACF Connector Specification — Fortnox
1. Purpose
This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with Fortnox.
Fortnox is treated as a source cloud accounting and business platform rather than merely as an import/export format.
The preferred ZAYAZ integration is API-native and uses:
- the Fortnox REST API for authoritative source retrieval;
- Fortnox WebSocket events for near-real-time change detection;
- OAuth 2.0 for customer authorization;
- service accounts and client credentials for production machine-to-machine operation where appropriate; and
- periodic API reconciliation as an integrity control.
The connector enables authorized Fortnox data to participate safely in:
- ESG screening;
- emissions estimation;
- invoice- and supplier-level classification;
- article and product classification;
- project and cost-center allocation;
- inventory and material-flow enrichment;
- evidence collection;
- reporting prepopulation;
- audit and assurance;
- supplier ESG workflows; and
- regulatory data-quality assessment.
The connector does not make accounting data equivalent to sustainability evidence merely because that data exists in Fortnox.
ACF determines:
- which Fortnox tenant is connected;
- which scopes the customer authorized;
- which relevant Fortnox product licences are available;
- which source resources can actually be accessed;
- what those records can reliably establish;
- what ZAYAZ may derive from them;
- what requires enrichment or primary evidence; and
- how each resulting sustainability value remains traceable to the source.
2. Connector model
Fortnox is an API-native, event-capable accounting connector.
The preferred production architecture is:
FORTNOX
│
┌───────────┴─── ────────┐
│ │
REST API WEBSOCKET
│ EVENTS
│ │
authoritative state change signal
│ │
└───────────┬───────────┘
▼
ZAYAZ API HUB
│
tenant profile
│
▼
TRUSTGATE
│
▼
ACF
┌────────────┼────────────┐
│ │ │
normalize validate classify
│ │ │
└────────────┼────────────┘
▼
CANONICAL DATA MODEL
│
┌────────────┼────────────┐
▼ ▼ ▼
MICE FOGE ZARA
│
▼
GOVERNED ESG DATA
The REST API remains the authoritative source interface.
The WebSocket stream provides change intelligence.
3. Fortnox tenant identity
Fortnox identifies each customer environment through a tenant.
ACF must preserve this tenant identity explicitly.
The source-connection identity is therefore:
Fortnox integration
+
Fortnox tenantId
+
ZAYAZ tenant
+
ZAYAZ organization
+
E-C-O Number
The Fortnox tenant ID may be resolved through Fortnox company information or other authorized identity mechanisms.
It must never be inferred from a company name.
4. OAuth 2.0 authorization
Fortnox uses OAuth 2.0 for API authorization.
The initial customer connection is established through an authorization flow in which the customer approves the requested scopes.
Conceptually:
ZAYAZ
│
▼
Fortnox authorization
│
▼
customer authentication
│
▼
scope consent
│
▼
authorization code
│
▼
token exchange
The authorization code is short-lived and must not be retained as a persistent credential.
5. Service accounts
Fortnox supports service accounts intended for service-to-service integrations.
This is especially appropriate for ZAYAZ production connections because the integration does not need to remain dependent on a named employee.
The model is:
Fortnox customer
│
system administrator
│
authorizes ZAYAZ
│
creates service-account consent
│
▼
ZAYAZ production connection
A service account is specific to the integration and customer.
6. Client credentials
For service-account connections, Fortnox supports OAuth 2.0 client credentials after the customer has given the required consent.
This should be the preferred long-term production authentication model.
ZAYAZ retains:
Client ID
+
Client Secret
+
Fortnox tenantId
and uses them to obtain short-lived access tokens.
This eliminates operational dependence on refresh-token rotation for the service-account path.
The client secret remains a high-sensitivity credential and must only exist in approved secret storage.
7. User-bound authorization
Authorization-code connections remain useful for:
- customer onboarding;
- interactive setup;
- user-specific integrations; and
- cases where service-account behavior is not appropriate.
Traditional authorization produces an access token and refresh token.
The access token is temporary.
Refresh tokens must be treated as secrets and replaced with the newly returned refresh token when refreshed.
For production service-to-service operation, however, the service-account client-credentials model is preferred where available.
8. Customer consent
Customer consent is a first-class ACF object.
The connector should distinguish:
integration exists
from:
customer consent exists
and from:
current access token exists
These are different states.
For service accounts, customer consent can continue independently of individual access tokens until revoked.
This allows ZAYAZ to create new access tokens without repeatedly involving the customer.
9. Scope model
Fortnox uses scopes to determine which API resource families an integration may access.
Examples include:
- bookkeeping;
- invoice;
- supplier invoice;
- supplier;
- customer;
- article;
- order;
- project;
- cost center;
- currency;
- assets;
- warehouse;
- archive; and
- salary.
ZAYAZ must request only the scopes genuinely needed for the approved integration profile.
10. Fortnox scopes are not read-only
This is a significant Fortnox-specific security consideration.
A Fortnox scope gives access to both read and write operations for the resource family.
The API does not provide a separate read-only scope.
Therefore the ZAYAZ permission model must be stricter than the Fortnox token.
Conceptually:
Fortnox token
│
└── read + write capability
ZAYAZ connector policy
│
├── READ allowed
└── WRITE blocked by default
Write operations require separate ZAYAZ authorization.
11. Effective capability
A Fortnox resource should not be considered available merely because ZAYAZ knows its endpoint.
Effective capability is:
API resource exists
+
scope granted
+
customer Fortnox licence
+
effective permissions
+
ZAYAZ policy
=
usable connector capability
This distinction is essential.
12. Product licence dependency
Many Fortnox API resources depend on the customer having the corresponding Fortnox product or module.
For example, access to warehouse functionality depends on the relevant Fortnox warehouse product.
This means that:
scope = warehouse
does not necessarily imply:
warehouse capability = usable
The customer connector profile records both authorization and underlying product capability.
13. Customer connector profile
Each activated connection produces:
ACF-FORTNOX-CUSTOMER-PROFILE
The profile should record:
- Fortnox tenant ID;
- connected company;
- authorized scopes;
- effective product capabilities;
- available resources;
- endpoint versions;
- financial-year context;
- WebSocket topic coverage;
- rate-limit policy;
- canonical mappings;
- connector version; and
- TrustGate registration.
This becomes the machine-readable source contract for that Fortnox tenant.
14. Test environments
Fortnox provides developer test databases.
They should be used before live customer activation.
The Fortnox developer environment allows multiple test databases to be created for integration development and demonstration.
The ZAYAZ development flow should therefore be:
Fortnox test database
↓
connector development
↓
source validation
↓
WebSocket testing
↓
lineage testing
↓
production activation
Test success does not prove customer production capability.
Production must still undergo its own preflight.
15. REST API
The Fortnox REST API is the authoritative source retrieval mechanism.
ZAYAZ uses it for:
- company information;
- accounts;
- financial years;
- vouchers;
- suppliers;
- customers;
- supplier invoices;
- customer invoices;
- orders;
- articles;
- projects;
- cost centers;
- currencies;
- assets;
- warehouse data;
- documents; and
- other authorized resources.
The current canonical API base is:
https://api.fortnox.se/3
Connector implementations must not rely on historical alternate hosts.
16. Source filtering
Fortnox provides source-side query parameters for many resources.
Where available, ACF should use them instead of retrieving complete populations unnecessarily.
Important controls include:
lastmodified
financialyear
financialyeardate
fromdate
todate
resource-specific filters
This enables efficient incremental synchronization.
17. lastmodified synchronization
The lastmodified parameter is especially useful as a polling fallback.
A typical incremental strategy is:
last successful watermark
↓
overlap window
↓
lastmodified query
↓
pagination
↓
deduplication
↓
new watermark
An overlap window should be used where appropriate so boundary timing does not cause missed records.
18. Pagination
Fortnox collection retrievals are paginated.
ACF should not assume a complete result from a single collection request.
The connector must explicitly handle:
- page;
- offset;
- limit; and
- Fortnox pagination metadata where provided.
The API default should not be interpreted as the full dataset.
19. Retrieval limits
Collection retrieval should be deliberately bounded.
ACF should prefer:
filtered request
+
controlled page size
+
deterministic processing
over:
retrieve everything
+
filter locally
This improves:
- source performance;
- ZAYAZ processing cost;
- rate-limit usage;
- privacy;
- recovery behavior; and
- synchronization latency.
20. Fortnox rate limits
Fortnox applies API rate limits per client ID and tenant.
ACF must therefore maintain a separate rate budget for each customer connection.
Conceptually:
Tenant A → own rate budget
Tenant B → own rate budget
Tenant C → own rate budget
This is favorable for a multi-tenant ZAYAZ connector because one customer does not inherently consume the request allowance of another.
21. Sliding-window control
Fortnox rate limiting operates over a short sliding window.
This means ZAYAZ must avoid short bursts even when the longer-term requests-per-minute average looks acceptable.
The API Hub should therefore use:
- token-bucket or equivalent pacing;
- tenant-level queues;
- adaptive concurrency;
- 429 handling;
- exponential backoff;
- jitter; and
- request priority.
Large reconciliation jobs should not be allowed to crowd out operational source retrieval.
22. WebSocket event stream
Fortnox provides a WebSocket-based real-time event interface.
This is one of the strongest features of the connector.
The stream consists of topics representing domains such as:
invoices
supplier-invoices
suppliers
projects
vouchers
...
Each topic contains an ordered sequence of events.
23. Event offsets
Each Fortnox WebSocket event has an offset within its topic.
ACF must persist the last safely processed offset.
The correct processing order is:
receive event
↓
validate
↓
durably register
↓
retrieve source entity if needed
↓
process
↓
commit ACF state
↓
persist offset
The offset must not be advanced before durable processing succeeds.
24. Event ordering
Fortnox guarantees ordering within the topic.
That provides a valuable source sequencing mechanism.
However, ZAYAZ should not infer a global ordering across unrelated topics.
For example:
invoice topic
and:
supplier topic
have their own event streams.
Cross-topic semantic relationships should be resolved through source state rather than assumed event ordering.
25. At-least-once delivery
Fortnox events use at-least-once delivery semantics.
Therefore duplicates are possible.
ACF event processing must be idempotent.
An event such as:
supplier-updated-v1
received twice must not create two independent source mutations.
The event offset and source identity support deduplication.
26. Minimal event payloads
Fortnox events intentionally contain minimal information.
An event answers:
What changed?
It may not answer:
What is the complete current object?
Therefore:
WebSocket event
↓
identify tenant
↓
identify resource
↓
retrieve current entity
↓
process authoritative source state
is the preferred pattern.
27. Multi-tenant WebSocket connection
Fortnox supports listening to multiple tenants through one WebSocket connection.
This is especially well suited to a SaaS connector.
The architecture can therefore be:
FORTNOX EVENT STREAM
│
┌────────────┼────────────┐
│ │ │
Tenant A Tenant B Tenant C
│ │ │
└────────────┼────────────┘
▼
ZAYAZ API HUB
│
tenant discrimination
│
┌────────────┼────────────┐
▼ ▼ ▼
ZAYAZ A ZAYAZ B ZAYAZ C
Tenant isolation remains mandatory even though the transport connection is shared.
28. Event replay
Fortnox supports replaying events from stored topic offsets for a limited historical window.
This gives ZAYAZ a recovery mechanism after:
- connector outage;
- deployment;
- network failure; or
- temporary processing interruption.
The connector should therefore persist topic offsets durably.
29. Replay-window protection
Event replay is not unlimited.
If ZAYAZ remains disconnected beyond the supported replay horizon, API reconciliation becomes mandatory.
The recovery hierarchy is:
short outage
↓
offset replay
replay unavailable / too old
↓
authoritative API reconciliation
The connector should alert before recovery risk approaches the replay boundary.
30. WebSocket coverage is not assumed complete
Not every Fortnox API resource necessarily has an event topic.
Therefore the synchronization architecture is hybrid:
resource has event support?
│
┌──┴──┐
yes no
│ │
WebSocket API
│ incremental
│ query
└──┬───┘
▼
reconciliation
The customer connector profile records which strategy applies to each material source domain.
31. Company information
Company information is a foundational connector resource.
It supports:
- source-company identification;
- tenant resolution;
- legal-entity matching;
- connector verification; and
- E-C-O Number resolution.
Company name alone must not determine identity.
Stable tenant identity and governed organization mapping remain authoritative.
32. Financial years
Fortnox bookkeeping data has financial-year context.
The connector must resolve the correct financial year before processing accounting records.
This is important because:
- account configuration can be year-dependent;
- vouchers are organized within financial years;
- historical periods can remain relevant;
- new years may not yet be configured; and
- ESG reporting periods may span or differ from financial-year boundaries.
The Fortnox financial-year ID therefore belongs in lineage where applicable.
33. Missing financial years
A customer may reach a new financial period without having created the corresponding Fortnox financial year.
This must be treated as a source configuration condition rather than silently worked around.
The correct behavior is:
source date
↓
financial year exists?
│
┌──┴──┐
yes no
│ │
process pause affected flow
+
request resolution
ZAYAZ should not invent accounting-period identity.
34. Chart of accounts
Fortnox accounts are valuable ESG classification inputs.
They may support:
- energy-spend screening;
- fuel screening;
- travel classification;
- waste expenditure;
- purchased-goods analysis;
- professional-services analysis; and
- materiality discovery.
But an account is only one signal.
Example:
Account 5611
+
Supplier
+
Invoice line
+
Article
+
Project
↓
classification
is stronger than:
Account 5611
↓
classification
35. Vouchers
Vouchers provide the core accounting record structure.
They may contain:
- bookkeeping date;
- voucher series;
- voucher number;
- account postings;
- amounts;
- projects;
- cost centers; and
- supporting evidence relationships.
For ESG purposes, voucher identity should be preserved as:
financial year
+
voucher series
+
voucher number
together with the relevant Fortnox tenant.
36. Voucher evidence
Fortnox supports linking files to vouchers.
This is highly useful for TrustGate.
The evidence chain may become:
ESG result
↓
MICE execution
↓
classified voucher row
↓
Fortnox voucher
↓
voucher file connection
↓
receipt / invoice / evidence file
The existence of a file does not prove the environmental interpretation of its contents, but it materially improves traceability.
37. Suppliers
Fortnox supplier master data is strategically valuable for ESG.
It can support:
- supplier identity;
- supplier spend aggregation;
- supplier-country enrichment;
- supplier questionnaires;
- Scope 3 analysis;
- CSDDD workflows;
- supplier-specific factor lookup;
- primary-data requests; and
- supplier evidence routing.
However:
known supplier
does not mean:
supplier-specific ESG data
Those remain different quality states.
38. Supplier invoices
Supplier invoices are often more valuable for ESG than general-ledger entries alone.
Potential signals include:
- supplier;
- invoice date;
- due date;
- currency;
- financial amount;
- accounts;
- project;
- cost center;
- line description;
- article references where available; and
- supporting documents.
This can materially improve classification and evidence quality.
39. Customer invoices
Customer invoices may support sustainability use cases such as:
- product or service revenue classification;
- customer-project allocation;
- product-level reporting;
- emissions-intensity denominators;
- downstream analysis; and
- evidence reconciliation.
Customer sales data must not be confused with supplier-side purchased-goods activity.
The semantic direction of the transaction must remain explicit.
40. Invoice lines
Line-level information is one of the primary quality upgrades available through accounting-system integration.
For example:
Invoice total
SEK 120,000
provides less ESG context than:
Line 1: 4,000 kg material A
Line 2: freight
Line 3: installation
where those details genuinely exist in the source.
ACF should retain line relationships rather than flattening everything into a single document total.
41. Articles
Fortnox articles can provide structured product or service identity.
Potential ESG uses include:
- product classification;
- service classification;
- quantity interpretation;
- supplier mapping;
- product-footprint linkage;
- waste/material classification;
- inventory analysis; and
- emissions allocation.
An article identifier is not itself an ESG category.
It requires semantic mapping.
42. Bundle articles
Fortnox is evolving its article, order and invoice APIs to support bundle articles.
ACF must therefore distinguish:
bundle
│
├── parent article
└── component articles
from an ordinary single article.
This is important because environmental meaning may exist at:
- bundle level;
- component level; or
- both.
The connector must preserve source structure rather than flattening bundle relationships incorrectly.
43. Endpoint versioning
Some Fortnox resources have newer versioned representations.
The connector must not assume that all endpoints evolve simultaneously.
The customer connector profile should record which resource representation is active for:
- articles;
- invoices;
- orders;
- offers; and
- any future versioned endpoint.
Experimental Alpha or Beta APIs must not become production dependencies without explicit ACF governance approval.
44. Projects
Fortnox projects are useful allocation dimensions.
They may support:
- construction-project footprinting;
- client engagement emissions;
- project procurement;
- project travel;
- project energy use;
- revenue versus emissions analysis; and
- project-level sustainability reporting.
A Fortnox project is mapped to the ZAYAZ project model before it is used for ESG allocation.
45. Cost centers
Cost centers can support organizational allocation.
Example:
Fortnox cost center
"Malmö"
↓
ACF mapping
↓
ZAYAZ site / business unit
↓
E-C-O scoped context
The mapping must be versioned.
A cost-center code must not automatically be interpreted as a physical site unless the mapping establishes that relationship.
46. Assets
Fortnox asset data may support ESG use cases involving:
- vehicles;
- machinery;
- buildings;
- equipment;
- capital goods;
- depreciation context; and
- asset-related procurement.
However, financial asset records may not contain the physical information needed for environmental calculation.
Enrichment may therefore be required.
47. Warehouse data
Fortnox Warehouse can provide a significant upgrade over pure financial data.
Potential information includes:
- articles;
- stock quantities;
- inbound movements;
- outbound movements;
- stock points;
- stock locations;
- cost information; and
- warehouse states.
This can help ZAYAZ understand physical flows, not only expenditure.
48. Warehouse material flows
A warehouse movement may provide:
article
+
quantity
+
stock point
+
direction
+
date
which is potentially much closer to an activity input than a financial posting.
For example:
SEK 250,000 material purchase
may be DQ1 or DQ2.
Where validated inventory data provides:
12,400 kg material
the calculation may potentially progress toward DQ3.
The methodological requirements must still be satisfied.
49. FIFO semantics
Fortnox Warehouse uses FIFO principles for inventory.
This can matter when ZAYAZ later develops:
- batch-level sustainability characteristics;
- product carbon passports;
- material provenance;
- recycled-content tracking; or
- supplier-specific inventory attribution.
Accounting FIFO does not automatically determine environmental provenance.
But preserving the source inventory semantics gives ZAYAZ a stronger foundation.
50. Stock points and locations
Warehouse stock points may correspond to physical warehouse facilities.
Where validated, this can support:
- facility allocation;
- regional factors;
- logistics modeling;
- inventory footprinting; and
- site-specific analysis.
The mapping must be explicit:
Fortnox stock point
↓
ZAYAZ facility mapping
↓
physical location
↓
jurisdiction / grid / logistics context
51. Currency
Fortnox provides currency-related resources and transaction context.
Spend-based ESG calculations must preserve:
source value
+
source currency
↓
governed currency conversion
↓
factor reference currency
↓
calculation
The normalized spend value is a ZAYAZ transformation.
It must not overwrite the Fortnox-native value.
52. VAT and accounting semantics
VAT and accounting fields can help interpret transaction meaning.
They may assist:
- net versus gross spend normalization;
- account validation;
- transaction classification; and
- financial reconciliation.
However:
Tax treatment is not an ESG methodology.
VAT metadata is a source signal, not an emissions factor.
53. ESG processing model
The source-to-result chain is:
Fortnox source
↓
ACF registration
↓
canonical mapping
↓
normalization
↓
classification
↓
method selection
↓
factor resolution
↓
MICE
↓
TrustGate
↓
governed ESG result
Fortnox tells ZAYAZ:
What accounting or business event occurred?
ZAYAZ determines:
What sustainability meaning can validly be derived from it?
54. Spend-based emissions
Fortnox is well suited to spend-based screening.
A calculation can use multiple contextual signals:
Voucher
+
Account
+
Supplier
+
Supplier invoice
+
Line
+
Article
+
Project
+
Cost center
↓
classification
↓
spend category
↓
factor resolution
↓
tCO2e
This is materially better than using the general ledger account alone.
55. Activity-based emissions
Activity-based methodology requires actual physical activity.
Examples include:
- kWh;
- litres;
- kg;
- tonnes;
- kilometres;
- passenger-km;
- tonne-km; and
- other method-compatible units.
A Fortnox monetary amount does not establish a physical quantity.
Likewise, an article quantity must be semantically understood before being treated as an ESG activity.
56. Data enrichment
Fortnox data can be combined with other governed ZAYAZ sources.
For example:
Fortnox supplier invoice
+
invoice PDF
+
supplier portal
+
meter data
+
approved factor
↓
governed ESG calculation
Every contributing source retains separate provenance.
57. Data-quality hierarchy
ACF applies the common five-level accounting data-quality hierarchy.
ACF-DQ1 — Accounting-only estimate
Typical inputs:
- voucher;
- account;
- supplier;
- financial amount;
- transaction text.
Typical use:
- screening;
- materiality;
- spend-based estimation.
ACF-DQ2 — Invoice-level data
Typical inputs:
- supplier invoice;
- customer invoice;
- line details;
- article;
- supporting document;
- structured source relationship.
This often improves classification substantially.
ACF-DQ3 — Activity data
Physical quantity and unit are available.
Examples:
8,900 kWh
1,350 litres
28 tonnes
6,500 km
This may support activity-based methodology.
ACF-DQ4 — Supplier-specific data
Data is attributable to the actual supplier, product, service or reporting relationship.
ACF-DQ5 — Verified primary data
Primary data has undergone the required validation or independent verification.
58. Quality upgrades
The quality model is progressive.
DQ1
Accounting estimate
│
▼
DQ2
Invoice-level estimate
│
▼
DQ3
Activity calculation
│
▼
DQ4
Supplier-specific result
│
▼
DQ5
Verified primary result
When better evidence becomes available, ZAYAZ may generate a new result.
The previous result remains part of the lineage.
59. Classification
A Fortnox ESG classification may combine:
- account;
- voucher;
- supplier;
- invoice;
- invoice line;
- article;
- order;
- project;
- cost center;
- transaction text; and
- warehouse information.
The classification remains ZAYAZ-derived unless Fortnox explicitly supplies the same semantic meaning.
60. Evidence linkage
Fortnox provides strong opportunities for accounting evidence linkage.
Potential evidence objects include:
- vouchers;
- invoice records;
- supplier invoices;
- archived documents;
- inbox files;
- voucher file connections;
- asset files; and
- article files.
A reporting value may therefore resolve through:
ESRS / VSME datapoint
↓
ZAYAZ result
↓
MICE execution
↓
classified activity
↓
Fortnox supplier invoice
↓
voucher
↓
source file
This creates an auditor-readable evidence chain.
61. WebSocket lineage
The event itself is also part of source lineage.
For event-driven changes, TrustGate can preserve:
Fortnox topic
+
event type
+
offset
+
tenantId
+
entityId
+
timestamp
followed by:
authoritative API retrieval
This shows both why ZAYAZ refreshed the entity and what authoritative state it subsequently processed.
62. FOGE prepopulation
FOGE may use validated Fortnox-derived information where it satisfies the reporting requirement.
For example:
supplier invoice
↓
validated activity
↓
MICE calculation
↓
evidence quality test
↓
reporting requirement
↓
FOGE prepopulation
FOGE must not confuse:
field available
with:
regulatory evidence requirement satisfied
63. VSME and ESRS
Fortnox may contribute valuable underlying information to VSME and ESRS reporting.
Possible inputs include:
- financial values;
- energy-related expenditure;
- supplier data;
- travel expenditure;
- asset information;
- purchasing data;
- inventory movements;
- project data; and
- calculated emissions.
Fortnox alone cannot establish complete disclosures relating to:
- policies;
- governance;
- due diligence;
- workforce practices;
- transition plans;
- biodiversity strategy;
- stakeholder engagement;
- targets; or
- narrative reporting.
64. ZARA behavior
ZARA can use the connector profile to explain:
- whether a Fortnox resource is available;
- whether the appropriate scope exists;
- whether a Fortnox licence is required;
- why data is missing;
- what source object produced a value;
- whether an event triggered a refresh;
- what quality level applies;
- why enrichment is required; and
- whether a value is Fortnox-native or ZAYAZ-derived.
ZARA must never collapse source fact and derived interpretation into one indistinguishable claim.
65. FOGE behavior
FOGE uses ACF to determine:
- source availability;
- data quality;
- evidence sufficiency;
- source preference;
- reporting-field eligibility;
- missing evidence; and
- required enrichment.
If the source is insufficient, FOGE requests evidence rather than manufacturing completion.
66. MICE behavior
MICE receives governed calculation inputs.
A calculation should identify:
- Fortnox tenant;
- source resource;
- source record;
- financial year;
- amount or activity;
- currency;
- unit where applicable;
- classification;
- method;
- factor;
- factor version;
- organization context;
- reporting period; and
- data-quality tier.
This allows deterministic reproduction.
67. COSE behavior
COSE compares available Fortnox evidence against methodological and regulatory requirements.
Example:
Requirement:
physical electricity consumption
Fortnox source:
supplier invoice with SEK amount only
Result:
activity evidence gap
The result should trigger enrichment rather than silent estimation unless an approved lower-quality spend method is explicitly permitted.
68. DaVE behavior
DaVE monitors technical and semantic connector health.
Signals include:
- authentication failure;
- consent revocation;
- scope change;
- rate-limit pressure;
- WebSocket disconnect;
- offset gap;
- replay-window risk;
- API failure;
- financial-year issue;
- endpoint-version change;
- supplier-resolution failure;
- unexpected nulls;
- reconciliation difference; and
- historical source mutation.
A connection can therefore be technically online while degraded for ESG purposes.
69. TrustGate behavior
TrustGate preserves:
Fortnox
↓
API / WebSocket source
↓
canonical mapping
↓
normalization
↓
classification
↓
calculation
↓
reporting output
↓
verification
The lineage survives:
- recalculation;
- source correction;
- cancellation;
- late posting;
- financial-year change;
- factor change;
- classification change;
- higher-quality evidence;
- manual override; and
- assurance review.
70. Historical accounting changes
Accounting systems can change historical records.
Examples include:
- late vouchers;
- corrected supplier invoices;
- cancellations;
- new payments;
- adjusted project allocations; and
- reopened accounting periods.
A material historical change triggers:
Fortnox mutation
↓
WebSocket or reconciliation
↓
DaVE detection
↓
TrustGate lineage event
↓
affected ESG result
↓
revalidation
↓
recalculation if required
Historical ESG results are not silently overwritten.
71. Locked periods
Where Fortnox exposes period-locking information, ACF should use it as an accounting-control signal.
A closed or locked period increases the significance of subsequent historical changes.
However, an accounting lock does not necessarily equal a sustainability reporting lock.
ZAYAZ maintains its own reporting lifecycle separately.
72. Accounting-agency use case
Fortnox is highly relevant for accounting-firm distribution.
An accounting consultant may activate an integration for a customer company.
Conceptually:
Accounting firm
│
├── Client A Fortnox
├── Client B Fortnox
├── Client C Fortnox
└── Client D Fortnox
│
▼
ZAYAZ ACF
│
separate tenants
│
▼
separate E-C-O Numbers
The accounting relationship must never collapse customer isolation.
73. Multi-client services
The Fortnox connector can support future accounting-partner services such as:
- VSME preparation;
- Scope 3 screening;
- emissions accounting;
- supplier-data collection;
- ESG advisory;
- reporting prepopulation;
- audit preparation; and
- continuous sustainability bookkeeping.
Each client remains a separately governed ZAYAZ tenant and evidence context.
74. Data minimization
Fortnox can contain more data than a specific ESG calculation requires.
ACF should therefore retrieve only the minimum data needed for the approved purpose.
For example:
Required:
supplier
invoice
amount
currency
account
project
does not justify retrieving unrelated:
salary records
customer records
employee absence
warehouse data
unless those resources are required for the governed use case.
75. Source-side minimization
Fortnox filters should be used whenever practical.
This reduces:
- API traffic;
- rate-limit usage;
- unnecessary data transfer;
- ZAYAZ storage;
- processing cost; and
- privacy exposure.
The default connector posture should be:
Retrieve deliberately, not exhaustively.
76. API change management
Fortnox evolves its API.
The connector must monitor:
- new resource versions;
- deprecated resource versions;
- changed validations;
- changed fields;
- changed scopes;
- changed event types; and
- changed endpoint behavior.
The customer connector profile should retain the source interface version actually used.
77. Alpha and Beta APIs
Fortnox makes experimental APIs available for early access.
These may be useful for development and future capability assessment.
They must not automatically become production dependencies.
The governance model is:
Alpha
↓
evaluation only by default
Beta
↓
controlled evaluation
Stable
↓
production eligible
Exceptions require explicit architectural approval.
78. Event-type versioning
Fortnox WebSocket event types are versioned.
For example:
supplier-updated-v1
The event-version suffix is part of the event contract.
API Hub must therefore route and validate events by:
topic
+
event type
+
event version
rather than merely by resource name.
79. Unknown event handling
If Fortnox introduces an event type that ZAYAZ does not recognize:
unknown event
↓
do not discard
↓
register telemetry
↓
pause semantic processing if required
↓
retrieve affected entity if safe
↓
alert API Hub / DaVE
The event stream must be forward-tolerant without silently misinterpreting new event semantics.
80. Recommended production architecture
The recommended production architecture is:
FORTNOX
│
┌─────────────┴─────────────┐
│ │
REST API WEBSOCKET
│ │
authoritative records change events
│ │
└─────────────┬───────────┘
▼
ZAYAZ API HUB
│
┌─────────────┼─────────────┐
│ │ │
OAuth tenant map rate control
│ │ │
└─────────────┼─────────────┘
▼
TRUSTGATE
│
source lineage
│
▼
ACF
┌─────────────┼─────────────┐
│ │ │
normalize validate classify
│ │ │
└─────────────┼─────────────┘
▼
CANONICAL DATA MODEL
│
┌─────────────┼─────────────┐
▼ ▼ ▼
MICE FOGE ZARA
│ │ │
└─────────────┼─────────────┘
▼
GOVERNED ESG OUTPUT
A reconciliation process operates alongside the real-time path.
81. Quick-start implementation
A controlled pilot should:
- create a Fortnox test database;
- register the ZAYAZ integration;
- configure required OAuth scopes;
- authorize the test tenant;
- resolve the Fortnox tenant ID;
- generate the customer connector profile;
- ingest a limited historical accounting period;
- map accounts, suppliers, invoices, projects and cost centers;
- validate financial-year handling;
- perform initial ESG screening;
- connect the WebSocket event stream;
- validate offset persistence and replay;
- verify API rate-limit handling;
- reconcile source state; and
- verify TrustGate lineage.
The pilot should not be considered production-ready merely because Fortnox API records can be retrieved.
82. Production implementation
Production should add:
- customer-approved service-account consent;
- client-credentials token operation;
- tenant identity registration;
- minimum-scope configuration;
- internal read-only enforcement;
- rate-limit control;
- durable WebSocket processing;
- topic-offset persistence;
- API entity rereads;
- scheduled reconciliation;
- source-capability profiling;
- endpoint-version monitoring;
- financial-year monitoring;
- TrustGate registration;
- DaVE diagnostics; and
- controlled recalculation.
83. Warehouse-enhanced implementation
For customers using Fortnox Warehouse, ACF can additionally map:
- stock points;
- stock locations;
- article quantities;
- inbound flows;
- outbound flows;
- stock balances; and
- warehouse-specific document states.
This can support future:
- product environmental footprinting;
- material-flow accounting;
- inventory footprinting;
- logistics analysis;
- circularity analysis; and
- product carbon passports.
Warehouse integration should therefore be treated as an optional but high-value ACF capability.
84. Hybrid ESG implementation
The strongest sustainability dataset will often combine Fortnox with non-accounting sources.
For example:
Fortnox
│
├── supplier
├── invoice
├── article
├── spend
└── project
+
supplier primary data
+
meter data
+
logistics data
+
approved emission factors
↓
high-quality ESG result
ACF acts as the accounting backbone rather than trying to force all sustainability data into Fortnox.
85. Limitations
The Fortnox connector has important limitations.
85.1 Accounting data is not complete ESG data
Fortnox records cannot independently satisfy every sustainability requirement.
85.2 Scopes are not read-only
ZAYAZ must enforce its own write controls.
85.3 Resource access depends on Fortnox products
An API scope does not guarantee underlying customer capability.
85.4 Event coverage is not assumed complete
Some resources may require incremental polling.
85.5 WebSocket events are minimal
An event often requires an API reread.
85.6 At-least-once delivery creates duplicates
Consumers must be idempotent.
85.7 Event replay is time-limited
Long outages require API reconciliation.
85.8 API rate limits constrain extraction
ZAYAZ must manage tenant-level API budgets.
85.9 Endpoint contracts evolve
Versioned resources require connector monitoring.
85.10 Financial values are not physical activities
Spend cannot silently be converted into physical quantities.
86. Connector activation gate
A production Fortnox connector should not activate until:
OAuth integration PASS
Customer consent PASS
Fortnox tenant identity PASS
Required scopes PASS
Resource licence capability PASS
Internal write policy PASS
Financial-year resolution PASS
Canonical mapping PASS
TrustGate registration PASS
Initial reconciliation PASS
Rate-limit control PASS
Monitoring PASS
If WebSocket synchronization is part of the selected production profile:
WebSocket connectivity PASS
Topic registration PASS
Offset persistence PASS
Replay test PASS
Duplicate handling PASS
Entity reread PASS
must also succeed.
87. Definition of done
The Fortnox connector is production-ready when ZAYAZ can demonstrate that it can:
- authenticate through OAuth 2.0;
- establish and retain valid customer consent;
- use service-account client credentials where configured;
- resolve the Fortnox tenant ID;
- map the tenant to the correct ZAYAZ organization and E-C-O Number;
- identify granted scopes;
- distinguish scope authorization from product licence capability;
- block unapproved API writes;
- retrieve required accounting resources;
- preserve Fortnox source identities;
- resolve financial-year context;
- paginate and filter source collections correctly;
- operate within Fortnox rate limits;
- connect to the WebSocket stream;
- separate events by tenant;
- process event types by topic and version;
- persist topic offsets;
- tolerate duplicate events;
- replay missed events within the supported recovery window;
- reread authoritative entities after minimal events;
- reconcile event-driven state against the API;
- map source records into the ZAYAZ canonical model;
- normalize and validate them deterministically;
- detect endpoint and resource-version changes;
- detect relevant historical accounting mutations;
- execute ESG screening without inventing missing activity;
- upgrade calculations when better evidence becomes available;
- preserve prior calculations and provenance;
- link source documents through TrustGate;
- support ZARA, FOGE, MICE, COSE and DaVE consumers;
- prevent cross-tenant data leakage; and
- reproduce any material ESG result from source to final output.
88. Source references
This connector specification is based primarily on current official Fortnox material covering:
- Fortnox Developer Portal;
- OAuth 2.0 authorization;
- authorization-code flow;
- access tokens;
- service accounts;
- client-credentials access;
- API scopes;
- product licence requirements;
- REST requests;
- query parameters;
- pagination;
- rate limits;
- WebSocket events;
- vouchers and supporting files;
- warehouse functionality;
- test environments;
- endpoint migration;
- versioned article/order/invoice APIs; and
- experimental Alpha and Beta APIs.
The current Fortnox API documentation remains authoritative for resource- and field-level implementation.
The ACF customer connector profile must be reviewed or regenerated when material changes affect:
- Fortnox scopes;
- customer licences;
- API endpoints;
- endpoint versions;
- WebSocket topics;
- event versions;
- authorization;
- customer consent;
- financial-year configuration;
- warehouse configuration; or
- canonical source mappings.
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-FORTNOX
provider:
namespace: fortnox.fortnox
name: Fortnox AB
product: Fortnox
runtime:
source_contract:
primary_api: rest_v3
event_transport: websocket
capability_rules:
effective_capability_dimensions:
- api_resource
- authorization_scope
- customer_license
- user_permission
- zayaz_policy
change_capture:
websocket:
supported: true
delivery_semantics: at_least_once
replay_window_days: 14
coverage_complete: false
reconciliation:
required: true
source_identity:
source_object_id_required: true
source_semantics:
warehouse_quantity:
activity_status: candidate
maximum_quality_after_semantic_validation: ACF-DQ3
requires_unit_and_business_semantics: true
evidence:
vouchers_strong_evidence_surface: true
files_strong_evidence_surface: true
extensions:
write_policy:
default: disabled
customer_context:
license_and_permission_discovery_required: true
governance:
status: active
last_verified: 2026-08-30
review_interval_days: 90
change_control_required: true
source_basis: connector_specification