How DataFlow's Accounting and Trading Modules Work Together
Updated
DataFlow (Clarity) runs accounting and trading on one database, so every module posts to the same set of records rather than exchanging files with the others. Sales and purchase ledgers, nominal accounts, stock, order processing and VAT all sit on that single database, and the modules share one set of customers, products and accounts. You can start with either the ledgers or the trading engine and add the remaining modules later, which suits UK businesses that want to consolidate a trading system and a separate accounting package without replacing everything at once.
The shared database is the mechanism
The important detail is not that DataFlow offers accounting and trading features, but that they write to the same place. When an order is processed, the resulting invoice posts to the ledger as part of the same transaction, so the trading side and the accounting side stay in step without imports or re-keying.
A practical example: a distributor raises a quote, converts it to an order, records a delivery and issues an invoice. Because order processing posts as it goes, the sales ledger entry and the stock movement are created from the same event. There is no month-end exercise to reconcile the order system against the accounts, and no one re-entering figures between two tools.
The same logic applies across modules:
- Shared master data. Customers, products and accounts are defined once and used by every module, so a new customer or product does not need to be created twice.
- Multiple companies. Any number of companies can run on one installation, which matters for groups that trade through more than one entity.
- VAT from the system. HMRC Making Tax Digital is built in, alongside EC Sales Lists, payment-practices reporting and an audit trail, rather than being stitched together by hand each period.
What each module covers
The modules fall into two groups, accounting and trading, and each posts to the same integrated database.
| Module | Group | What it handles |
|---|---|---|
| Nominal Ledger | Accounting | Chart of accounts, journals, cash book, reconciliation and period close |
| Trade Ledgers | Trading | Sales and purchase ledgers, receipts, payments, allocations, statements, aged debt and BACS |
| Order Processing | Trading | Quotations, orders, deliveries, invoices, credit notes and works orders, posting as they go |
| Stock Control | Trading | Catalogue, movements and layered pricing for physical goods |
The Nominal Ledger is the general ledger everything posts to. Trade Ledgers brings the sales and purchase sides together with credit control and BACS. Order Processing is the trading engine that turns quotes into orders, deliveries and invoices. Stock Control covers the physical-goods side, including catalogue, movements and layered pricing.
Where to start
Because every module shares the same database, the entry point depends on which side of the business is causing the most friction.
- Start with the ledgers if your accounting is the priority and trading is currently handled adequately elsewhere, or if you want the nominal and trade ledgers consolidated first.
- Start with the trading engine if orders, deliveries and invoicing are the pain point, and let the accounting modules follow.
- Add the rest when ready. Modules added later share the existing customers, products and accounts, so growth does not require a migration between systems.
The pattern DataFlow describes is common to distribution, accountancy and trading businesses that have not consolidated: trading and accounts in separate systems, documents filed in many places, no single view of stock and margin, and VAT compliance assembled by hand. If more than one of those applies, the shared-database design is the part worth evaluating first.
What to check before deciding
The site describes the module structure and the single-database design but does not publish pricing, so cost and licensing terms need to be confirmed directly, for example through the demo booking offered on the site. Before committing, it is worth confirming:
- Which modules you need on day one and which can wait.
- How your existing customer, product and account data would be brought across.
- Whether your current order volumes and company structure fit a single installation with multiple companies.
For a UK business that trades and accounts in one operation, the value lies in removing the reconciliation step between trading and finance. The test is whether your current month-end involves re-keying or matching figures between two systems; if it does, a single-database setup addresses that directly.