Many organisations raise invoices from the information system (IS), but enter receipts into their accounting software.
Some record expenses in their IS but pay them through the accounts.
Quite often there’s re-keying of data from the IS data silo to the accounting data silo. Or there might be a loss of detail as day-to-day transactions are bundled up into journals entered by hand.
Sometimes, it’s where things happen that makes it awkward - e.g. if your debtor chasing has to run from your information system but your aged debtors only exists in the accounts … it’s hard.
But these days it doesn’t have to be difficult.
And you shouldn’t accept that data you need to run the organisation is inaccessible.
All half-decent accounting software has two silo busting features:
1. Data import
You can import transactions, sales and purchase accounts into your accounting software
2. Access to accounting data through ODBC
You can expose your accounting data to your other software, so it can be combined with other management information where it’s needed.
Imagine that you run conferences or membership subscriptions from your IS, because that’s what the IS is set up to do, but your treasurer insists that all money must be entered directly into the accounting software.
When it comes to debtor control - chasing people for their subscriptions or conference payments - you can go one of three ways:
1. You record payments in both systems, which is inefficient, prone to error, and silly.
2. Your debtor control is a manual process initiated in the IS (showing who should have paid), tallied in the Accounts (showing who has paid), then manually cross-checked, flagged, and chased through the IS (Dear Jim, your subs are overdue), which is probably even more inefficient, more prone to error, and sillier.
3. The right way ….
Our view of the right way to control this operation is to:
A. Export sales invoices from IS to Accounts
That is, have a managed routine to automatically export new sales accounts and new sales invoices from the IS, import them into the Accounts, confirm safe import and so doing mark the invoices as ‘exported’ in the IS.
B. Use a window into the Accounts from the IS
Set up a read-only ODBC (Open Database Connectivity) connection into the Accounts, exposing the Sales Ledger. Have an IS routine which can be run on demand, which takes active customers/members, finds their record in the Accounts, reads the debtor balance and stamps it on a display field in the IS, then traverses any paid sales invoices under that account and updates the corresponding IS invoice record to indicate amount paid.
Sounds a bit complicated but it’s really pretty straight forward with most Accounts software.
And it means that in your IS, you can see timely info on who’s paid and who hasn’t, so you can run simple debtor chasing reports, emails/form letters - much better than re-keying and much more efficient than disconnected silos.
It means a lot less data entry in the Accounts software, and a single point of entry for all information – that’s a tell-tale sign of good business systems architecture.
Most Windows-based accounts software (Sage, SunSystems, etc.) and information systems combinations should be capable of delivering the above.
IS/Accounts integration might seem boring to some people, but we love it, and we love good business systems architecture.
If it’s interesting to you, you can see we’d welcome a call, even if it’s just as a sounding board.