Prepare every transaction in the stream.
Keep every financial system in control.
Connect live sales, refunds, cash, card and inventory data from hundreds of kiosks and stores. The stream combines each transaction with its financial context, transforms it into a ledger-ready event, applies approved controls and returns the posting result from Exact, AFAS or another financial system to the current batch state.
For finance operations, controllers and distributed retail teams, working with IT, tax, security and the owners of each connected financial system.
Distributed Ledger Operations
One network. Clear agreements for each participant.
A growing retail network can create thousands of daily transactions across tills, kiosks, payment services and inventory systems. Point-to-point integrations repeat mappings and controls for every location. Finance teams then reconcile missing, duplicate or unbalanced entries after the fact. One contextual stream can control the path from source transaction to confirmed posting and return the result for close and reconciliation.
Store, kiosk or transaction service
Supplies sales, refund, tender, tax and inventory events under one versioned source contract.
Finance and control team
Defines account mappings, balancing conditions, periods, thresholds and exception responsibilities.
Exact, AFAS or another financial system
Receives accepted entries through its authorised API and returns a posting result or rejection.
Retail operations
Sees which locations and batches are complete, awaiting correction or blocked from financial posting.
Processes to connect
Bring processing to the data your services already produce.
Keep business context, purpose, rules, destinations and expected responses in one approved definition. Personal context is included where it matters. Each accepted input is transformed for backend processing, and the result returns to the current state.
Transaction to controlled ledger entry
Use legal entity, location, period, tax, currency and account context to transform an accepted sale or refund into the configured debit and credit lines.
Posting request to current financial state
Send an idempotent request to the selected financial endpoint. Its acknowledgement or rejection updates the batch and reconciliation context; submission alone is not a confirmed posting.
Distributed exception to accountable recovery
Route duplicates, missing mappings, closed periods and rejected entries to the responsible team without stopping valid stores or hiding an incomplete close.
Focused capability
Runtime ledger controls
Turn operational transaction data into ledger-ready events at runtime. Apply entity, location, period, tax and account context, execute the approved controls and return each financial-system response to the stream.
The full operating model, controls and example now have their own page.
Explore runtime ledger controlsExample operation
See how an agreement becomes an outcome.
The same input, relevant context and approved rule version produce the same rule-based result. Changed facts or agreements can change the next result, with the applied version recorded.
1. trigger
A kiosk submits its end-of-shift batch containing sales, refunds, card totals and cash count.
2. context
Combine the source identity with the legal entity, store, terminal, accounting period, currency, tax codes, tender mappings, prior batch state and applicable approval threshold.
3. rule
Reject a duplicate batch, require balanced debit and credit totals, hold an unknown account or closed period, and require approval when a configured variance exceeds its limit.
4. outcome
Prepare and submit only the accepted entries to the configured Exact, AFAS or other financial endpoint. Keep the batch pending until a posting reference returns, then update its financial state; route unresolved entries to finance operations.
5. evidence
Retain the source and batch references, mapping and rule versions, validation results, approved payload reference, endpoint response and resulting status under the applicable retention policy.
Validate late or duplicate events, unavailable destinations and rule changes before activation. Historical evidence explains the earlier decision; a new action must meet the conditions that apply when it is executed.
Rules in context · EU and Netherlands
Turn applicable requirements into explicit processing conditions.
The responsible organisation determines the applicable obligations and approves their translation into executable rules. These sources guide that work; they are not a certification of the solution.
Financial administration and retention
Determine which source data, ledger records, cash-register details and evidence form part of the administration. The Dutch Tax Administration states that core records normally have a seven-year retention requirement, with exceptions and possible written arrangements for other data.
Dutch Tax Administration: retentionExact endpoint contract
Confirm the available Exact product API, authentication, entity model, request limits and response behaviour for the customer's environment. A named integration target is not a claim that every Exact edition exposes the same operation.
Exact: developer documentationAFAS connector validation
Configure the authorised App Connector and relevant Get or UpdateConnector. AFAS documents endpoint-specific checks, including that a financial entry must balance before it can be created.
AFAS Profit: UpdateConnectorPersonal data minimisation
If a transaction contains customer or employee data, limit each financial output and retention rule to the information needed for its defined purpose while preserving required accounting evidence.
GDPR Article 5 on EUR-LexSource review: 20 September 2026. Confirm the applicable requirements for your service and jurisdiction when defining the operation.
Business value
Measure the work you can remove.
Build the business case from the integrations, manual work and evidence preparation this process actually replaces. Include platform fees, implementation, validation and remaining operating costs.
Location integration effort
Reuse one transaction and ledger configuration across stores and kiosks. Measure implementation and change hours per added location.
Reconciliation and close effort
Detect incomplete, duplicate and unbalanced entries before they disappear into downstream jobs. Measure manual corrections and time to an accepted close.
Financial control evidence
Keep the applied mapping, checks, approval and endpoint response together. Measure the work needed to explain a sampled posting or exception.
Start small, then expand
Prove the value in one bounded process.
Start with one transaction type, one representative location and one financial endpoint. Validate normal sales, refunds, duplicate batches, a closed period, a missing mapping and an endpoint rejection. When finance accepts the posting and evidence behaviour, add representative high-volume locations before scaling the same configuration across the network.
Scope and responsibility boundary
Datastreams does not replace the point-of-sale system, payment processor or financial system. Exact, AFAS or another selected system remains authoritative for the posting it accepts. Confirm endpoint rights, schemas, limits, tax mappings, security duties and retention with the responsible owners before production use. Capacity for hundreds of locations is established with representative event volumes and close-window testing.
Agree the baseline and acceptance criteria
- Time to onboard a new kiosk or store
- Accepted, rejected and pending entries per batch
- Duplicate and unbalanced entries stopped before posting
- Time from source event to confirmed financial-system reference
- Manual corrections and finance hours per close
- API failures, retries and unresolved exceptions
- Integration maintenance and audit-preparation effort
Compare a representative period before and after. Expand only after the responsible owners accept the processing behaviour, evidence and measured value.