Skip to main content

ZAYAZ Integration Brief — SIE

How ZAYAZ integrates with the Swedish Standard Import and Export format​

ACF Connector ID: ACF-SIE Framework: ZAYAZ Accounting Connectivity Framework Primary market: Sweden Document version: 1.0.0

1. Integration overview

What SIE is​

SIE — Standard Import and Export — is an open Swedish standard for transferring accounting data between accounting systems and other financial applications.

Its purpose is system independence: accounting data can be exported from one application and consumed by another without requiring the receiving application to understand the source system's proprietary database structure.

The classic SIE family consists of progressively richer formats:

FormatPrimary contentRelevance to ZAYAZ
SIE 1Opening and closing account balancesHigh-level financial screening
SIE 2SIE 1 + periodic/monthly balance movementsPeriod and trend analysis
SIE 3SIE 2 + object/dimension balancesCost-centre/project analysis
SIE 4SIE 3 + vouchers and transactionsPreferred classic format for ZAYAZ
SIE 4iTransaction postings intended for importLimited analytical context
SIE 5Extended XML-based accounting formatPreferred where richer source data is available

For ZAYAZ, the strategic value of SIE is not that it contains every ESG datapoint.

Its value is that it provides a standardized accounting-data entry point across a large number of Swedish accounting systems.

Rather than building a proprietary ingestion model for every source system before a customer can begin, ZAYAZ can use SIE as a common accounting-data interface and then enrich the resulting data where ESG reporting requires greater specificity.

Why ZAYAZ integrates with SIE​

Accounting records contain a significant number of signals relevant to ESG analysis:

  • purchased goods and services
  • energy expenditure
  • fuel expenditure
  • travel
  • logistics
  • waste services
  • leased assets
  • capital expenditure
  • suppliers
  • operational locations and dimensions
  • period movements
  • cost allocation

These signals can help ZAYAZ determine:

  1. what ESG-relevant activity appears to exist;
  2. where material exposures may be located;
  3. what data can already be used;
  4. what can be estimated using an approved methodology;
  5. what additional primary evidence is needed.

SIE therefore acts as an initial evidence and discovery layer, not as a substitute for all ESG source data.

Supported integration methods​

ACF separates the SIE payload from the transport mechanism.

This distinction is mandatory.

SIE defines the accounting-data format. It does not itself define a REST API, authentication model, webhook protocol or continuous synchronization mechanism.

ZAYAZ can receive SIE through:

File import​

The native and simplest integration method.

A customer exports a supported SIE file from the accounting system and uploads it into ZAYAZ.

API-mediated SIE import​

Where an accounting system exposes SIE exports through an API, ZAYAZ may retrieve the SIE payload through an accounting-system-specific adapter.

The API belongs to the source system.

The accounting payload remains SIE.

Scheduled import​

Where a source application or integration service can generate files or expose exports on a schedule, the ZAYAZ API Hub may orchestrate recurring ingestion.

Event-driven ingestion​

Possible only where the originating platform exposes an event or webhook mechanism.

This is not a SIE-native capability.

Manual fallback​

Manual SIE upload remains the canonical fallback mechanism.

This is particularly valuable for pilots, historical imports, smaller companies and systems for which a direct API connector has not yet been implemented.

2. Integration architecture

The canonical architecture is:

ACCOUNTING SYSTEM
      │
      ├── SIE file export
      ├── API-delivered SIE export
      └── Scheduled SIE export
              │
              ▼
      ZAYAZ API HUB / ACF
              │
      ┌───────▼────────┐
      │ Ingestion Gate │
      └───────┬────────┘
              │
      Parse + validate
              │
              ▼
       Canonical mapping
              │
              ▼
      ZAYAZ DATA MODEL
              │
     ┌────────┼─────────┐
     ▼        ▼         ▼
   FOGE   TrustGate   ZARA
     │        │         │
     └────────┼─────────┘
              ▼
       ESG computation
              │
              ▼
       Reporting / APIs

File​

File import is the baseline SIE integration.

The ingestion process must:

  1. receive the original file;
  2. identify the SIE format/version;
  3. generate a cryptographic source hash;
  4. preserve the original file;
  5. validate structure and mandatory fields;
  6. parse supported records;
  7. register warnings and unsupported content;
  8. map accepted data to the ZAYAZ canonical model.

The original source must remain immutable within the evidence chain.

API​

SIE must not be represented in ACF as having its own native API.

Instead:

Source-system API
       ↓
SIE export payload
       ↓
ACF-SIE parser

Where an accounting platform provides a richer native API, ZAYAZ may eventually prefer that connector over SIE for continuous operation while retaining SIE as:

  • onboarding route;
  • fallback;
  • historical import mechanism;
  • reconciliation source.

Webhook / event​

Status: Conditional

A SIE payload can be triggered by an event only where another system provides the event mechanism.

Example:

Accounting period closed
        ↓
Source-system webhook
        ↓
ZAYAZ source adapter
        ↓
Request SIE export
        ↓
ACF-SIE ingestion

Scheduled sync​

Status: Conditional

Scheduled synchronization can be implemented through:

  • source-system API;
  • controlled file location;
  • secure file-transfer service;
  • integration middleware;
  • scheduled export process.

The schedule must be recorded separately from the SIE connector profile.

Manual fallback​

Status: Supported by architecture

If automation is unavailable:

Export SIE
   ↓
Upload
   ↓
Validate
   ↓
Process

The resulting ESG processing should be identical after successful ingestion, regardless of whether the payload arrived manually or automatically.

3. Data available to ZAYAZ

SIE capability depends heavily on the format variant and the implementation of the originating accounting system.

ZAYAZ must therefore evaluate actual field availability, not merely assume availability because a SIE file exists.

Capability matrix​

Data domainSIE 1–2SIE 3SIE 4SIE 5ACF treatment
Company/accounting context✓✓✓✓Supported
Chart of accounts✓✓✓✓Supported
General-ledger balances✓✓✓✓Supported
Period movementsSIE 2✓✓✓Conditional by format
Transactions——✓✓Supported
Vouchers——✓✓Supported
Cost centres—ConditionalConditionalConditionalSource dependent
Projects—ConditionalConditionalConditionalSource dependent
Supplier master—LimitedLimitedConditionalEnrichment may be required
Customer master—LimitedLimitedConditionalEnrichment may be required
Supplier invoices——LimitedConditionalDo not assume full invoice object
Customer invoices——LimitedConditionalDo not assume full invoice object
Invoice lines——LimitedConditionalUsually requires enrichment
Reporting currencyConditionalConditionalConditionalConditionalValidate explicitly
Transaction currencyLimitedLimitedLimitedConditionalNever infer silently
VAT/tax informationLimitedLimitedLimitedConditionalUse cautiously
Electronic attachments———ConditionalValidate availability
Fixed-asset informationLimitedLimitedLimitedConditionalSIE 5 offers richer support

General ledger​

SIE provides a strong basis for general-ledger ingestion.

The ZAYAZ canonical mapping should preserve:

  • source account code;
  • source account name where available;
  • period;
  • balance;
  • source chart-of-accounts context;
  • source file;
  • source entity;
  • source accounting period.

Transactions and vouchers​

SIE 4 is particularly important because it exposes transaction-level accounting data.

ZAYAZ should preserve the relationship:

Source file
  → Voucher
      → Transaction
          → Account
          → Dimension/object
          → Amount

This relationship forms the accounting lineage used by later classification and ESG calculations.

Supplier records​

Supplier identity must be treated cautiously.

A transaction description containing a supplier name is not equivalent to a validated supplier master record.

Where supplier identity is required for:

  • Scope 3 supplier analysis;
  • supplier engagement;
  • supplier ESG Passport;
  • customer-specific allocation;
  • E-C-O™ Number matching;

ZAYAZ must establish a reliable supplier identifier.

Where SIE cannot supply that identifier, ACF should trigger enrichment from:

  • invoice evidence;
  • accounting-system API;
  • procurement data;
  • supplier master import;
  • user-confirmed mapping.

Customer records​

The same principle applies to customers.

Customer identity must not be inferred from free text where downstream allocation or reporting depends on an authoritative relationship.

Invoices​

Accounting postings may indicate that an invoice transaction occurred.

They do not automatically provide the complete invoice.

ZAYAZ should distinguish:

ACCOUNTING POSTING
≠
INVOICE OBJECT
≠
INVOICE DOCUMENT
≠
INVOICE LINE

Each has a different evidential value.

Invoice lines​

Invoice-line data is particularly valuable for ESG because it may contain:

  • product description;
  • quantity;
  • unit;
  • material;
  • fuel type;
  • energy volume;
  • transport service;
  • origin/destination information.

ACF-SIE must never assume that these fields are present.

Where invoice-line detail is required, ZAYAZ should request a richer source.

Cost centres and projects​

Where dimensions or objects are available, ZAYAZ can use them to improve:

  • organizational allocation;
  • site-level analysis;
  • business-unit reporting;
  • project attribution;
  • cost-centre ESG dashboards;
  • emissions allocation.

The semantic meaning of each dimension must be mapped before automated ESG use.

VAT and tax information​

Tax-related metadata can support classification but should not be treated as a complete tax model.

For example, VAT accounts may help identify transaction types, but ZAYAZ must not derive regulatory or ESG meaning from VAT treatment alone.

Currency​

The reporting currency should be preserved where explicitly available.

For emissions calculations based on spend, ZAYAZ must also preserve:

  • monetary currency;
  • transaction/reporting date;
  • FX conversion where applicable;
  • emissions-factor currency;
  • emissions-factor price year where relevant.

Currency normalization must form part of the calculation lineage.

Attachments​

Electronic document support is materially richer in SIE 5.

Where a document is embedded or referenced, ZAYAZ may link it into TrustGate as supporting evidence.

A document reference must still be validated for:

  • accessibility;
  • integrity;
  • content type;
  • tenant ownership;
  • relationship to the accounting record.

4. How ZAYAZ processes the data

4.1 Ingestion​

Every import generates an ingestion event.

Minimum metadata:

tenant_id
client_id
connector_id
source_system
source_system_version
SIE_variant
source_filename
source_hash
import_timestamp
import_method
import_user_or_service
parser_version

The original file is retained as source evidence.

4.2 Schema mapping​

The SIE-specific source structure maps to the ZAYAZ Canonical Data Model.

Example:

SIE transaction amount
        ↓
financial.transaction.amount
SIE account
        ↓
financial.account.code
SIE object/dimension
        ↓
financial.dimension

Downstream ZAYAZ engines should consume canonical fields rather than SIE-specific tags wherever possible.

4.3 Normalization​

Normalization can include:

  • date formatting;
  • decimal normalization;
  • currency handling;
  • account mapping;
  • dimension mapping;
  • organization mapping;
  • supplier/customer identity resolution;
  • period alignment;
  • duplicate handling.

The source value must always remain available alongside the normalized value.

4.4 Validation​

Validation occurs in layers:

Structural validation​

Is the file structurally valid?

Semantic validation​

Do accounting relationships make sense?

Completeness validation​

Are expected records present?

Referential validation​

Do transactions correctly reference accounts, periods and dimensions?

ESG-readiness validation​

Is enough information available for the intended ESG use case?

A file can therefore be:

valid SIE but insufficient ESG evidence.

These concepts must remain separate.

4.5 Classification​

Accounting data can then be classified into ESG-relevant categories.

Examples:

Electricity expenditure
Fuel
Air travel
Hotels
Freight
Waste collection
Purchased materials
Professional services
Leasing
Capital equipment

Classification may use:

  • account mapping;
  • transaction description;
  • supplier mapping;
  • invoice evidence;
  • known procurement category;
  • historical classification;
  • AI-assisted classification;
  • governed rules.

AI classification must retain confidence, evidence and version information.

4.6 ESG enrichment​

Where accounting data is insufficient, ACF dispatches an enrichment request.

Example:

SIE:
Electricity expense = SEK 125,000
            ↓
FOGE requirement:
Electricity consumption = kWh
            ↓
ACF:
Physical activity unavailable
            ↓
Request:
Electricity invoice / meter data

The accounting record is not discarded.

It remains a secondary reconciliation source.

4.7 Calculation​

Once sufficient data exists, the relevant computation engine can perform the calculation.

Example:

Spend amount
×
approved spend-based emission factor
=
estimated CO₂e

or:

18,450 litres diesel
×
approved fuel emission factor
=
CO₂e

Each calculation must reference:

  • method;
  • input data;
  • factor;
  • factor source;
  • factor vintage;
  • conversions;
  • formula version;
  • calculation timestamp.

4.8 Evidence linkage​

TrustGate links the resulting datapoint back through its evidence chain.

Reported ESG datapoint
        ↓
Calculation
        ↓
Method
        ↓
Emission factor
        ↓
Normalized source record
        ↓
Original SIE transaction
        ↓
Original SIE file

Where additional evidence exists:

Original SIE transaction
        ↕
Invoice
        ↕
Supplier-specific evidence

5. ESG use cases

Emissions screening​

SIE 4 is especially useful for initial emissions screening because transaction data can be grouped and classified by expenditure.

The purpose is to answer:

Where are the organization's likely emissions exposures, and where should better data be collected first?

Screening should not be confused with final verified emissions measurement.

Scope 1​

Potential uses include identification of expenditure associated with:

  • fuel;
  • gas;
  • company vehicles;
  • combustion;
  • refrigerant-related services.

Accounting data may identify candidate activities.

Physical consumption and organizational-boundary evidence may still be required.

Scope 2​

Accounting transactions can identify:

  • electricity suppliers;
  • electricity expenditure;
  • heating/cooling expenditure;
  • energy-related accounts.

For more precise Scope 2 calculation ZAYAZ may require:

  • kWh;
  • site;
  • country/grid region;
  • energy source;
  • supplier;
  • contractual instruments;
  • renewable-energy evidence.

Scope 3​

SIE can be highly useful for initial Scope 3 screening because several Scope 3 categories are closely related to procurement and financial transactions.

Potential categories include:

  • purchased goods and services;
  • capital goods;
  • fuel- and energy-related activities;
  • transportation and distribution;
  • waste;
  • business travel;
  • leased assets.

GHG Protocol permits spend-based estimation for purchased goods and services when more specific methods are not feasible, while supplier-specific, hybrid and physical activity methods can provide more specific information when available.

ZAYAZ should therefore treat spend-based calculations as part of a data-upgrade pathway, not necessarily the endpoint.

Purchased goods and services​

This is one of the strongest SIE use cases.

Financial transactions
      ↓
Procurement classification
      ↓
Spend screening
      ↓
Material suppliers/categories
      ↓
Targeted primary-data collection

ZAYAZ can use accounting data to determine where supplier engagement creates the greatest value.

Energy​

Accounting data identifies energy-related financial activity.

Invoices or meter data upgrade this to physical consumption.

Travel​

Travel accounts and suppliers can identify likely travel activity.

More precise calculation can use:

  • ticket data;
  • route;
  • distance;
  • travel class;
  • hotel nights;
  • vehicle type.

Transport​

Financial transactions can identify logistics providers and transport expenditure.

Activity-based calculation may require:

  • tonne-km;
  • distance;
  • shipment weight;
  • vehicle type;
  • fuel;
  • logistics-provider data.

Supplier analysis​

Where supplier identity is sufficiently reliable, SIE-derived procurement data can support:

  • supplier-spend ranking;
  • supplier ESG prioritization;
  • Scope 3 hotspot identification;
  • supplier invitation into ZAYAZ;
  • primary-data requests;
  • supplier-risk screening.

VSME and ESRS population​

SIE can prepopulate or support fields for which validated accounting data is relevant.

It cannot independently populate the full sustainability statement.

Examples of areas requiring other evidence include:

  • policies;
  • targets;
  • governance;
  • workforce characteristics;
  • biodiversity information;
  • due diligence;
  • stakeholder engagement;
  • narrative disclosures;
  • transition plans.

FOGE must determine applicability and required evidence field by field.

6. Data-quality hierarchy

ACF-SIE uses a progressive data-quality model.

ACF-DQ1 — Accounting-only estimate​

Example:

SEK 500,000 spent on air travel

Useful for:

  • screening;
  • hotspot identification;
  • initial spend-based estimates.

ACF-DQ2 — Invoice-level data​

Example:

Supplier: Airline X
Invoice: 12345
Travel service: SEK 8,500

Improves:

  • supplier attribution;
  • classification;
  • evidence quality.

ACF-DQ3 — Activity data​

Example:

Stockholm → London
Economy
1 passenger

or:

Electricity: 100,000 kWh

Allows activity-based calculation.

ACF-DQ4 — Supplier-specific data​

Example:

A supplier provides product-specific or allocated emissions directly.

This may replace generic estimates where the data satisfies ZAYAZ quality requirements.

ACF-DQ5 — Verified primary data​

The highest level contains validated primary data plus verification evidence.

The hierarchy is deliberately upgradeable:

DQ1
 ↓
DQ2
 ↓
DQ3
 ↓
DQ4
 ↓
DQ5

ZAYAZ must preserve prior versions when a calculation is upgraded.

A change in result caused by improved data quality must not be mistaken for a change in real-world performance.

7. Traceability and audit trail

Every ESG result derived from SIE must retain sufficient lineage to reconstruct its treatment.

Source system​

Where known:

  • accounting-system name;
  • system version;
  • exporting application;
  • organization;
  • accounting period.

Source record​

Preserve identifiers necessary to locate the original accounting record.

Example:

SIE file
→ voucher series
→ voucher number
→ transaction
→ account
→ dimension

Transformation​

Every transformation must identify:

  • transformation rule;
  • rule version;
  • original value;
  • normalized value;
  • timestamp.

Factor​

Where an emissions factor is used:

  • factor ID;
  • source;
  • dataset;
  • geography;
  • year/vintage;
  • unit;
  • uncertainty metadata where available.

Method​

Examples:

  • spend-based;
  • activity-based;
  • supplier-specific;
  • hybrid;
  • estimated;
  • allocation method.

Calculation​

Store:

  • inputs;
  • formula;
  • conversions;
  • factor;
  • calculation engine/version;
  • result;
  • recalculation history.

Verification status​

Possible lifecycle states may include:

unvalidated
validated
evidence_required
reviewed
verified
superseded
rejected

TrustGate remains the authority for evidence and verification status.

8. Limitations

The limitations section is mandatory for every ACF connector.

SIE cannot provide every ESG datapoint​

SIE is fundamentally an accounting-data standard.

It should not be treated as a complete sustainability-information model.

Accounting spend is not physical activity​

Example:

Fuel spend = SEK 100,000

does not automatically tell ZAYAZ:

fuel type
litres
vehicle
country
combustion context

An accounting transaction is not an invoice line​

ZAYAZ must not fabricate product or activity detail from a monetary posting.

Account codes are indicators, not absolute ESG truth​

A particular account may usually contain travel, fuel or electricity, but company-specific accounting practices can vary.

Mapping therefore requires governance.

Supplier names must not be guessed​

Where supplier identity is ambiguous, the record must be marked unresolved or sent for enrichment.

Scope must not be inferred solely from the ledger​

The existence of expenditure does not automatically determine:

  • Scope 1;
  • Scope 2;
  • Scope 3 category;
  • organizational boundary;
  • operational control.

Financial data cannot replace missing non-financial evidence​

SIE cannot by itself establish:

  • policies;
  • workforce practices;
  • human-rights due diligence;
  • governance processes;
  • environmental targets;
  • biodiversity impacts;
  • stakeholder engagement.

ZAYAZ must prefer better evidence when available​

If validated physical or supplier-specific data becomes available, ZAYAZ should evaluate whether the existing lower-quality estimate should be replaced.

9. Security and controls

Authentication​

SIE itself contains no platform authentication model.

Authentication is therefore handled by:

  • ZAYAZ;
  • source-system connector;
  • integration service;
  • secure transfer mechanism.

Permissions​

Imports must be tenant-scoped.

The user or service performing the import must have explicit authority for the relevant:

  • tenant;
  • legal entity;
  • client;
  • accounting source.

Encryption​

Production implementation requires:

  • encryption in transit;
  • encryption at rest;
  • secure key management.

Tenant isolation​

A SIE file belonging to one organization must never be queryable, discoverable or used for model context by another tenant unless an explicit authorized data-sharing relationship exists.

Logging​

Log at minimum:

  • file receipt;
  • user/service identity;
  • source hash;
  • validation result;
  • parser result;
  • rejected records;
  • transformations;
  • enrichment actions;
  • manual overrides;
  • recalculations;
  • export/use by downstream engines.

Sync monitoring​

Where automated ingestion is configured, monitoring should include:

  • last successful sync;
  • expected sync time;
  • failed imports;
  • malformed files;
  • record-count anomalies;
  • duplicate detection;
  • missing periods;
  • schema change alerts.

For manual upload, the corresponding concept is import monitoring, not continuous sync monitoring.

10. Implementation options

Option A — Quick-start​

Best for: pilot, onboarding, smaller companies.

Accounting system
      ↓
Export SIE 4 / SIE 5
      ↓
Manual upload to ZAYAZ
      ↓
Automated processing

Advantages:

  • minimal IT involvement;
  • fast onboarding;
  • works across multiple accounting systems;
  • suitable for historical analysis;
  • useful for proving ESG automation.

Option B — Production integration​

Best for: recurring service delivery.

Possible architecture:

Accounting system
      ↓
Scheduled export / secure transfer / API
      ↓
ZAYAZ API Hub
      ↓
ACF-SIE

Additional production controls:

  • automated validation;
  • duplicate prevention;
  • period controls;
  • monitoring;
  • alerts;
  • reconciliation.

Option C — Continuous synchronization​

Best for: higher-volume clients where the source accounting system supports automation.

Important:

Continuous synchronization is not a native SIE feature.

The source accounting platform or source-specific ZAYAZ connector must provide the transport mechanism.

Example:

Accounting API
     ↓
Scheduled/event trigger
     ↓
Generate/retrieve SIE
     ↓
ACF-SIE
     ↓
Incremental ZAYAZ processing

Where a source system offers a richer native API, ACF may recommend migration from SIE batch import to the dedicated source-system connector.

SIE should remain available as a fallback and reconciliation mechanism.

11. Technical status

The technical status deliberately distinguishes between:

  1. what the SIE standard supports;
  2. what the ACF architecture supports;
  3. what has been implemented and production-tested in ZAYAZ.

These must never be treated as the same thing.

Initial connector status​

ComponentStatus
ACF-SIE specificationSupported
Official SIE standard understandingSupported
SIE 1–4 canonical mapping definitionPlanned
SIE 4 parserPlanned
SIE 5 XML parserPlanned
Manual upload workflowPlanned
Structural validationPlanned
ZAYAZ canonical mappingPlanned
TrustGate lineage integrationPlanned
FOGE availability integrationPlanned
ZARA ACF retrievalPlanned
Automated source-system transportRequires configuration
Scheduled SIE retrievalRequires configuration
Webhook/event ingestionRequires configuration
Continuous synchronizationRequires configuration
Production certificationPlanned
Formal SIE-Gruppen software approvalNot claimed

Promotion rules​

A capability must not move from planned or in_development to supported until:

  1. implementation exists;
  2. automated tests pass;
  3. representative source files have been tested;
  4. invalid-file handling has been tested;
  5. canonical mapping has been validated;
  6. lineage has been verified;
  7. security controls have passed QA;
  8. documentation reflects production behavior.

ZARA guardrail​

ZARA must answer capability questions using both:

source_standard_status
+
zayaz_connector_status

For example:

Incorrect

“SIE 5 provides supplier information, therefore ZAYAZ currently imports supplier data from SIE 5.”

Correct while connector status is planned

“SIE 5 can carry richer accounting information, including subledger-related information. ACF-SIE models this capability, but the ZAYAZ production connector must be implemented and validated before it is represented as currently supported.”

This distinction is mandatory across sales, documentation, FOGE automation and AI-generated responses.

Canonical ACF principle​

The role of ACF-SIE is not merely to import a file.

It is to answer, in a deterministic and machine-readable way:

What can ZAYAZ know from this accounting source, how trustworthy is that knowledge, what can it be used for, and what additional evidence must be requested before ZAYAZ makes a stronger claim?

That principle applies equally to future connectors such as Xledger, Fortnox, Visma, Microsoft Dynamics 365 Business Central, NetSuite and SAP.

One connector definition. One canonical data contract. Multiple ZAYAZ consumers.



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.

provider-extension.yamlGitHub ↗
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-SIE
provider:
  namespace: sie.sie_group
  name: Föreningen SIE-Gruppen
  product: SIE
runtime:
  source_contract:
    source_kind: open_accounting_data_standard
    supported_variants:
      - SIE1
      - SIE2
      - SIE3
      - SIE4
      - SIE4I
      - SIE5
    preferred_esg_variants:
      - SIE4
      - SIE5
    continuous_sync_native_to_standard: false
  interfaces:
    file_import:
      native_to_standard: true
    api_transport:
      native_to_standard: false
      requires_originating_system_or_adapter: true
    webhook:
      native_to_standard: false
      requires_originating_system_or_adapter: true
  capability_rules:
    source_variant_material: true
  source_semantics:
    SIE4:
      granularity: voucher_and_transaction
      preferred_for_transaction_screening: true
    SIE5:
      structure: xml
      enhanced_electronic_document_support: true
  evidence:
    SIE5_electronic_document_reference_supported: true
    SIE5_electronic_document_attachment_supported: true
  extensions:
    synchronization:
      scheduled_and_continuous_modes_require_external_source_capability: true
governance:
  status: active
  last_verified: 2026-08-30
  review_interval_days: 90
  change_control_required: true
  source_basis: connector_specification
GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ