Typed once: why finance tools belong inside the ERP

Most payables teams could recite the routine. An invoice arrives by email. Someone saves the PDF, opens Spire beside it, and types the vendor, the invoice number, the dates, each line, the tax and the GL account. They check it, post it, and file the PDF somewhere sensible.

Each step is reasonable. Together they amount to a second copy of work that already exists in two places: the vendor’s invoice and the ERP that will hold it.

The cost is not only time

Hours are the obvious cost, and every controller has a rough idea of their own. The less visible cost is error, and the slow drift between what was keyed and what was meant:

• Transposed digits and misplaced decimals.
• An expense coded to the account it went to last time, which was wrong last time too.
• An invoice dated into a period that is already closed.
• The same invoice entered twice, once from the email and once from the paper copy.

The usual remedy is a side spreadsheet that tracks what has been entered. That is a third copy, and the drift starts again.

What integration should mean

“Integrates with your ERP” covers everything from a nightly CSV export to a system that writes through the ERP’s own rules. For finance work the difference matters. A useful integration:

• Writes through the ERP’s own rules. Ingrid posts to Spire through Spire’s own API wherever it can, so Spire’s balances move as if the entry had been keyed in Spire.
• Checks what actually landed. After each post, Ingrid reads the transaction back from Spire and records only what Spire holds.
• Fails without duplicating. If a post’s response is lost, Ingrid checks Spire before doing anything else. It never blindly sends it again.
• Keeps reference data current. Vendors, GL accounts, purchase orders, terms and tax codes sync from Spire every few minutes, so the people coding invoices are choosing from the real chart.
• Leaves the server closed. Ingrid’s Data Connector runs on your own server and connects out, so no inbound firewall port is opened, and your Spire sign-in details stay on that server.
• Shows its working. Every change is recorded with who, when and what changed.

One invoice, through Ingrid Payables

Here is the same routine with the copying taken out. The steps that need judgement are still there; the typing is not.

1. The invoice arrives by upload, a phone photo, or the company’s own AP email address. Mail from senders nobody has approved is held for a person to allow or block.
2. Ingrid reads the vendor, number, dates, totals, tax and lines, with a confidence score on each field, and matches the vendor to its Spire record.
3. GL accounts are suggested from that vendor’s past invoices. A reviewer’s corrections are kept beside Ingrid’s original reading, which is never overwritten.
4. Exact repeats are refused. The same invoice number with a different total needs a person to confirm it is a separate invoice.
5. Lines are matched to the purchase order and receipt, within a tolerance, and an invoice that totals more than the PO has left is held.
6. The invoice goes through the company’s approval chain, then posts to Spire and is read back.

Where people stay in the loop

Taking the typing out is not the same as taking people out. Every step Ingrid takes in Payables is a suggestion a person confirms. A submitter cannot approve their own invoice. When an invoice’s tax does not match the vendor’s Spire tax code, someone confirms it before it posts, and that is logged. An invoice dated into a locked Spire period is stopped before anything is written, with a plain message.

The same principle runs through Bank Rec: statement lines are matched to the book, nothing is posted without a person’s approval, of either the entry itself or the rule that posts it, and a posting counts as done only once it has been found in the book.

The point of it

Integration is not there to remove the accountant. It is there to remove the copy, so the time goes into the invoices that need a decision rather than the ones that only needed typing.