Financial integration & eCommerce

If Infoworks is about nothing else, it is about helping you to expose your charity services to a broader public through web based self-service - i.e. giving stakeholders controlled access to enter-it-yourself windows into your information system.

And none are more apt for this treatment than services that require credit / debit card payment.

There's now a mature and competitive market of eCommerce card payment sites we can integrate to seamlessly.

We're able to knit the payment itself into the broader workflow associated with the service in question - for example, a course booking will automatically reduce the remaining places available and prompt a check by the admin team, or a membership purchase will automatically trigger an approval and welcome process.

For organisations currently handling large numbers of manual/cheque payments, the savings from web based self payment are immense, and the client gets a faster and better service.

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:

• Data import

  You can import transactions, sales and purchase accounts into your accounting software

• Access to accounting data through ODBC/API's

  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:

• You record payments in both systems, which is inefficient, prone to error, and silly.
• 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.
• 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. Our developers have experience of interfacing to many payment and account systems.