Making scaffolding software talk to your accounts

In owner-managed scaffolding firms the accounts package is usually the oldest and least negotiable system in the business. Whatever else changes, invoices come out of it and the bookkeeper knows it. Any new system has to fit around that, and how well it does frequently decides whether the new system survives its first year.

What integration should actually save

The work worth eliminating is re-keying: a job priced in one place, invoiced by retyping the figures in another, with the hire periods and variations reconciled by hand. That is where the errors come from, and it is also where a fortnight of unbilled extended hire quietly disappears.

A useful integration pushes an agreed value — job, variations, hire to date — into the accounts package as a draft invoice for somebody to check and send. It does not need to be cleverer than that, and integrations that try to be usually create reconciliation problems of their own.

Draft, not automatic

The instinct is to automate the invoice entirely. In practice a draft that a human approves is almost always the right design, because scaffolding invoices carry judgement — whether a variation has been agreed, whether a client's retention applies, whether an extended hire is being charged or absorbed.

Automating that removes the moment where somebody notices a variation was never agreed with the client, and finds out instead when the invoice is disputed.

Questions worth asking a vendor

• –Which accounts packages are genuinely supported, as opposed to available via a third-party connector
• –Does it push drafts or post directly, and can that be changed
• –What happens when an invoice is edited in the accounts package afterwards
• –How are credit notes and partial invoicing handled
• –Who owns the connection when it breaks — the vendor, the accounts package, or you
• –Does it cost extra, and is it included at your tier

The last two are the ones that produce unpleasant surprises. Integration is frequently priced separately, and when it stops working after an update to either system, ownership of the problem can be genuinely unclear.

The bookkeeper has a veto, and it is usually right

Whoever raises the invoices will be the heaviest user of the join between the two systems and is rarely consulted before purchase. They are also the person who knows the things that will break it: the client who needs applications rather than invoices, the job that is always split across two nominal codes, the retention that has to be handled a particular way.

Involving them in an evaluation costs an hour and routinely surfaces a constraint that would otherwise appear in month two.

In practice: the integration that made more work

A firm connects its new system to its accounts package and sets invoices to post automatically on job completion. Within a month the bookkeeper is reversing entries — jobs marked complete on site before the final variation was agreed, producing invoices that had to be credited and reissued.

The integration worked exactly as designed. The design assumed a job is finished when site says it is, which is true operationally and not true commercially, and nobody had asked the person who would find out.

Common mistakes

• –Evaluating without the person who actually raises invoices
• –Posting automatically rather than producing a draft for approval
• –Assuming a connector listed on a website is a supported integration
• –Not establishing who owns the connection when it breaks
• –Discovering that integration is priced separately after choosing the product
• –Treating a job marked complete on site as ready to invoice

Where this connects: what breaks, and whose problem it is

Integrations break. Either system updates, an authentication token expires, a field changes, and invoices quietly stop flowing — usually noticed when somebody asks why a job has not been billed. The failure is rarely dramatic and frequently invisible for a fortnight.

Which makes two questions worth settling before signing rather than at the first outage: who owns the connection when it stops working, and how you would notice. A firm that finds out from an unbilled job has no monitoring; one that gets told by the system has a considerably shorter outage.

• –Establish who owns the connection when it breaks
• –Ask how a failure surfaces — silence is the usual answer
• –Check whether integration is priced separately or included at your tier
• –Confirm which accounts packages are genuinely supported
• –Push drafts for approval rather than posting automatically
• –Involve whoever raises invoices before choosing