Overview
Twinfield is a cloud-based accounting platform widely used by mid-market businesses, accounting firms, and multi-entity organisations in the Netherlands and across Europe. Part of the Wolters Kluwer group, Twinfield provides general ledger accounting, accounts receivable, accounts payable, fixed assets, project accounting, and the reporting infrastructure that professional financial administration requires. For organisations that use Twinfield as their financial system of record, integration between Twinfield and the surrounding operational systems — ERP platforms, e-commerce systems, payroll systems, custom operational tools, and reporting infrastructure — is a common and often business-critical requirement.
Twinfield's integration interface differs from the REST API model used by more modern accounting platforms. Twinfield uses a SOAP-based XML API that has been available since the platform's early years, alongside a more recent OAuth 2.0 authentication layer that replaces the earlier session-based authentication. The API provides access to Twinfield's core accounting objects — transactions, customers (debtors), suppliers (creditors), accounts, cost centres, dimensions, and the XML transaction posting that writes journal entries to the general ledger.
The Twinfield API's XML-based structure, its dimension model for cost centre and project allocation, and its transaction posting conventions are specific to Twinfield's architecture and require platform-specific knowledge to use correctly. The transaction XML that posts a sales invoice to Twinfield differs significantly from the REST JSON payloads that Exact Online or AFAS use — understanding the Twinfield XML schema, the required header and line structure, and the dimension codes that map to accounts and cost centres is prerequisite for building reliable Twinfield integrations.
We build Twinfield integrations for Dutch and European businesses, accounting firms, and software platforms that need to connect their operational systems to Twinfield's financial administration — covering the full range of Twinfield's accounting data domains and the integration patterns that production Twinfield connectivity requires.
What Twinfield Integration Covers
OAuth 2.0 authentication. Twinfield's current authentication model uses OAuth 2.0 through the Wolters Kluwer identity platform.
OAuth application registration: the Twinfield application registered in the Twinfield developer portal — the client ID and client secret for the OAuth application. The redirect URI for the authorisation code flow. The scopes that control API access.
Authorisation code flow: the OAuth 2.0 authorisation code flow for user-facing integrations. The authorisation URL that redirects the user to Twinfield's login page, the user authentication, the consent to grant the application access to the Twinfield organisation. The authorisation code returned to the redirect URI, exchanged for access token and refresh token via POST https://login.twinfield.com/auth/authentication/connect/token.
Client credentials flow: for server-to-server integrations where no user interaction is required. The token request with grant_type=client_credentials, the client ID and client secret, and the Twinfield-specific scope. The access token for automated integration processes.
Token management: Twinfield access tokens expire after a defined period. The refresh token used to obtain a new access token before expiry — the token refresh logic that maintains continuous access without re-authentication. The token storage that persists the refresh token across service restarts.
Cluster determination: Twinfield organises accounts across clusters (server clusters). After authentication, the integration must determine which cluster hosts the target company — the GET https://api.twinfield.nl/webservices/processxml.asmx discovery endpoint or the user information endpoint that returns the cluster for the authenticated user's organisation. The cluster-specific base URL (https://{cluster}.twinfield.com/) used for all subsequent API calls.
SOAP XML API structure. Twinfield's API uses SOAP-based XML communication rather than REST JSON.
SOAP endpoint: the Twinfield ProcessXml service endpoint at https://{cluster}.twinfield.com/webservices/processxml.asmx for XML-based operations. The SOAP envelope structure that wraps every Twinfield API request — the <soapenv:Envelope> with the <soapenv:Header> containing the access token and the <soapenv:Body> containing the Twinfield-specific XML payload.
Header authentication: the <Header> element in the Twinfield SOAP request that contains the access token and the company code — <AccessToken> with the OAuth bearer token and <CompanyCode> with the Twinfield company identifier. The company code that scopes the operation to a specific Twinfield administration within the organisation.
ProcessXml operation: the primary Twinfield SOAP operation — <ProcessXmlString> that accepts a Twinfield XML document and returns an XML response. The XML document posted to ProcessXml varies by operation type — transaction posting, master data retrieval, dimension queries — but all follow the pattern of XML wrapped in the SOAP envelope with the authentication header.
Response parsing: the SOAP XML response that Twinfield returns — the XML payload within the <ProcessXmlStringResult> element. The response XML that contains the result of the operation — success confirmation for transaction posts, data records for read operations, or error messages for failed operations. The XML parsing that extracts the relevant data from the response structure.
Transaction posting. The core Twinfield integration operation — posting journal entries and accounting transactions to the Twinfield general ledger.
Transaction XML structure: the Twinfield transaction XML that defines a journal entry. The <transaction> element with the <header> defining the transaction-level attributes and the <lines> collection of debit and credit entries. The header with <code> (the journal code — the transaction type like VRK for sales, INK for purchases, MEM for memorials), <date> (the transaction date in YYYYMMDD format), <period> (the accounting period in YYYY/PP format), <currency> (the ISO currency code), <number> (the transaction number — omit for auto-numbering), and <description> (the transaction description).
Transaction line structure: each <line> in the transaction with <type> (detail for regular lines, vat for VAT lines, total for total lines used in some transaction types), <dim1> (the primary dimension — the general ledger account code), <dim2> (the secondary dimension — the debtor or creditor code for receivables and payables), <debit> or <credit> (the amount), <vatcode> (the VAT code for VAT lines), <description> (the line description), and <value> (the amount as an alternative to debit/credit).
Sales invoice posting: the Twinfield VRK (verkoop — sales) transaction that records a sales invoice. The header with the sales journal code, the invoice date, the period, the debtor reference in the <invoicenumber> field. The lines with the debtor account in dim1 of the total line, the revenue account in dim1 of the detail lines, and the VAT lines for each VAT rate applied. The balanced transaction where debits equal credits.
Purchase invoice posting: the Twinfield INK (inkoop — purchase) transaction for supplier invoices. The creditor code in dim2 of the total line, the expense accounts in dim1 of the detail lines, and the VAT reclaim lines.
General ledger entries: the MEM (memorial) transaction for adjustments, accruals, and other general ledger entries that do not fit the debtor/creditor invoice model. The balanced debit/credit entries across general ledger accounts.
Cost centre allocation: the <dim3> element in transaction lines for cost centre allocation — the cost centre code that attributes the transaction amount to a specific cost centre or project within Twinfield's dimension model. The dimension codes that must exist in Twinfield before they can be referenced in transaction lines.
Master data access. Reading Twinfield's master data — account codes, dimensions, cost centres, VAT codes.
Read XML operations: the <read> XML operation type in Twinfield for retrieving master data. The <type> element specifying what to read — dimensions for account and dimension data, transactions for transaction history. The <code> element for filtering to a specific record.
General ledger accounts: reading the chart of accounts from Twinfield — the dimension data for BAS (balance sheet) and PNL (profit and loss) account types. The account code, description, account type, and VAT applicability that the integration uses to map internal account codes to Twinfield codes.
Debtor (customer) data: the DEB dimension type for Twinfield debtors — the customer code, name, address, credit limit, and payment terms. Reading debtors for customer master data synchronisation, and creating or updating debtors when new customers are added.
Creditor (supplier) data: the CRE dimension type for Twinfield creditors — the supplier code, name, address, bank account, and payment terms. The creditor master data that purchase invoice posting requires.
Cost centres: the KPL dimension type for Twinfield cost centres and projects. The cost centre codes that transactions reference for management accounting allocation.
VAT codes: reading Twinfield's configured VAT codes and their percentages — the VAT code mapping that ensures the integration uses the correct Twinfield VAT codes when posting transactions with Dutch BTW rates.
Query XML operations. Searching and filtering Twinfield data with the browse/query interface.
Browse data: the Twinfield browse functionality for querying transaction history and master data with filters. The <browse> XML operation with filter criteria — date range, journal code, dimension code — that retrieves matching records. The browse columns specification that selects which data fields to return.
Transaction history: querying posted transactions from Twinfield for reconciliation, reporting, and audit purposes. The date-range query that retrieves all transactions within a period. The dimension filter that retrieves all transactions for a specific debtor or creditor.
Open items: querying open items — unpaid invoices and unresolved transactions — from Twinfield's accounts receivable and accounts payable modules. The open item query that feeds cash flow management and dunning systems.
Company and office structure. Twinfield's multi-company organisation model.
Company codes: each Twinfield administration has a company code that scopes all operations. The company code in the SOAP authentication header that determines which administration the operation targets. Multi-company integrations that operate across multiple Twinfield administrations within the same Twinfield organisation.
Office structure: the officeCode in Twinfield that identifies the legal entity — relevant for multi-entity organisations where different companies share a Twinfield organisation but have separate accounting administrations.
Period and year management. Twinfield's accounting period structure.
Period notation: Twinfield uses YYYY/PP period notation — 2024/01 for January 2024, 2024/12 for December 2024. Some journal types use YYYY/00 for opening entries. The period calculation that converts a transaction date to the correct Twinfield period notation.
Open and closed periods: Twinfield periods can be open or closed — posting to a closed period returns an error. The period status check that verifies the target period is open before submitting transactions. The error handling that correctly identifies period-closed errors and either rejects the transaction or adjusts the posting period to an open period.
Year-end processing: the Twinfield year-end that closes the fiscal year and opens the next. The integration behaviour around year-end — handling the transition period when the current year is being closed and the next year is already open.
Error handling. Twinfield's XML error responses and the handling they require.
Error response structure: Twinfield returns errors within the XML response — the <messages> element in the response with <message> elements containing error codes and descriptions. The error code that identifies the specific problem — validation errors for missing required fields, period-closed errors for transactions in closed periods, dimension-not-found errors for references to non-existent codes.
Validation errors: the pre-posting validation that Twinfield performs — required fields, valid dimension codes, balanced transactions, open periods. The validation error response that identifies exactly which field or line failed validation, allowing the integration to surface actionable error information.
Retry logic: the error types that warrant retry (transient server errors) versus those that require application-level handling (validation errors, closed periods). The retry with backoff for transient failures and the error escalation for persistent failures.
Integration Patterns
Operational system to Twinfield. The most common Twinfield integration pattern — transactions generated in an operational system posted to Twinfield for financial administration. The e-commerce system that posts sales invoices to Twinfield as they are generated. The payroll system that posts salary journal entries to Twinfield after each pay run. The project management system that posts project cost entries to Twinfield's project accounting module.
Twinfield to reporting infrastructure. Reading Twinfield financial data for management reporting, consolidation, and analytics. The reporting system that queries Twinfield transaction history and balance data for period-end reporting. The consolidation system that reads multiple Twinfield company administrations and produces combined management accounts.
Debtor and creditor synchronisation. Keeping customer and supplier master data consistent between Twinfield and CRM, ERP, or e-commerce systems. The new customer created in the CRM propagated to Twinfield as a debtor. The supplier onboarded in the procurement system created as a Twinfield creditor.
Accounting firm platform integration. Accounting firms that use Twinfield for client administrations connecting their practice management and client communication tools to Twinfield — reading transaction data for client reporting, posting correcting entries, and managing period-end processes programmatically.
Technologies Used
- C# / ASP.NET Core — primary Twinfield integration implementation using .NET's
System.ServiceModelfor SOAP communication and the Twinfield .NET client library where applicable - Python — Twinfield integration for Python-based data pipelines and reporting tools using
zeepor direct HTTP for SOAP requests - TypeScript / Node.js — Twinfield integration for JavaScript-based platforms using
soapnpm package or direct HTTP XML construction - Rust / Axum — Twinfield integration for high-performance data processing pipelines
- SOAP / XML — Twinfield ProcessXml API communication
- OAuth 2.0 — Twinfield authentication via the Wolters Kluwer identity platform
- SQL (PostgreSQL / MySQL) — synchronisation state, transaction mapping, dimension code cache, error log
- Redis — access token caching, synchronisation job coordination, retry state
- Hangfire / scheduled jobs — scheduled transaction posting, periodic reconciliation, master data synchronisation
- Docker — containerised integration service deployment
- GitHub Actions — CI/CD pipeline for integration service deployment
Twinfield in the Dutch Accounting Ecosystem
Twinfield occupies a specific position in the Dutch and European accounting software market — the cloud accounting platform preferred by mid-market businesses and accounting firms that require more capability than simple bookkeeping tools provide, but operate in the European market where Twinfield's compliance, localisation, and cloud architecture make it the practical choice over SAP or Oracle for their scale.
For businesses and accounting firms that have standardised on Twinfield, the integration requirement is almost universal — the operational data that flows through the business needs to appear in Twinfield's financial administration automatically rather than through manual re-entry. The SOAP XML API, while less developer-friendly than modern REST APIs, is mature and stable — Twinfield integrations built to handle its XML conventions, its OAuth authentication, and its dimension model work reliably over time.
Twinfield Connected to Your Financial Operations
Twinfield integrations built to production standards — correct OAuth 2.0 token management with cluster determination, robust SOAP XML construction and response parsing, transaction XML that correctly maps to Twinfield's journal structure, dimension code validation before posting, period status checking that prevents closed-period errors, and the monitoring that surfaces posting failures before they cause financial reconciliation gaps.