Every vendor demos well, because the document in the demo is one they picked in advance. You're choosing software that will read the payment documents your customers send, match them against your open invoices and post them into Xero or QuickBooks Online. RemitClear builds software in this category, and we answer all four questions about ourselves below.
The four questions
- What is your straight-through rate, and does a person opening a document and clicking approve count as touching it?
- What does it do when the money does not add up, both when the lines do not sum to the printed total and when a credit cannot be fully applied?
- What can it write to my ledger, and what can it only read?
- What happens after it posts something wrong, where do I reverse it, and what is left behind?
Ask them on the call, then test every answer. Bring your ten worst documents to the demo and watch them processed live. Price, security certifications and onboarding are not on the list because procurement already asks those. These four are the ones a polished demo can hide. They work whether the vendor calls the category remittance processing or cash application software. Two smaller checks are worth making: whether the vendor publishes a named subprocessor list (ours is here), and whether your ledger has volume ceilings (the Xero batch payment limit).
1. What is your straight-through rate, and what counts as touched?
"Of the documents a customer like me sends in a month, how many go from arrival to posted with nobody changing anything? Does a person opening it and clicking approve count as a change?"
Extraction accuracy is counted per field, on documents the vendor chose, and a straight-through rate is counted per document and comes out of your workflow, so the two are not the same measure. A tool can read 99.9 per cent of characters correctly and still put a person on every document, because one wrong line opens the whole document. Whenever a percentage comes up, ask what the denominator is, since a share of fields, a share of lines and a share of whole documents are three different figures.
A good answer is a document-level rate with its denominator stated, every document from live customers over a stated window, along with an account of what the tool holds back even when it is confident. A weak answer is a bare percentage with no unit attached to it, or one that counts every document a person opened and approved unchanged. A tool that posts everything would score full marks on that measure and have no fail-safes at all.
How to verify it
Generate the number yourself instead of accepting theirs. Run a fortnight of your real documents through a trial and count three buckets: posted with nobody opening them, opened and approved unchanged, and edited. The third bucket is the only one that predicts your workload, and it's the one vendor figures fold into the second.
Then split that bucket by payer, because exceptions concentrated in one or two formats are worth raising before you sign, and exceptions spread evenly across every payer mean the tool isn't reading your class of document.
Our answer
We publish a match rate of 99 per cent across standard remittance formats, counted per remittance rather than per field or per line, with anything the matcher is unsure about flagged for your review. Each document carries one verdict, however many lines it has. We call it a match rate rather than a straight-through rate, because a document can match perfectly and still be held for a person on purpose. Unattended posting stays off until you turn it on, and a document whose ledger state makes the allocation a judgement call waits for you however cleanly it read. Ask us for a straight-through rate on your own documents, and there's more on where that line sits in when to let matches post without review.
2. What does it do when the money does not add up?
"Two cases. The lines don't sum to the total printed on the document. And a credit on it can't be fully applied against anything open. In each case, does it post anyway, adjust something to balance, or stop and tell me?"
All three behaviours exist in products on the market, and which one you get decides whether the software removes work or moves it onto whoever does the bank reconciliation. If it posts anyway you're left with a bank line that won't reconcile, and if it adjusts something to balance you're worse off again, because the ledger looks right while the error stays out of sight until somebody queries an invoice that was part-paid months ago. Stopping costs a minute at the time instead of an hour at month end.
A good answer says what stops, what the person is shown, and what they do next. A weak answer is "our accuracy means that does not really happen". Listen out for a tool that parks the unexplained difference in a suspense or clearing account, because the ledger balances after that and finding the problem has become your job.
How to verify it
Edit a line amount on a real remittance so the lines no longer sum to the printed total, and put it through. Then take one carrying a credit, and apply that credit elsewhere in your ledger first, so there's nothing open left for it to land on. Ignore the message on screen and check whether the deposit ties out to the penny in the bank reconciliation. Deduction treatment is covered in handling deductions on remittances.
Our answer
RemitClear stops in both cases. A document whose lines do not add up to its printed total is held back from unattended processing and waits for a person. If a matched credit cannot be applied in full, no payment is posted at all, so the deposit cannot tie out short, and the message names the credit that needs fixing. Anyone in your workspace can override a total mismatch and post anyway, because a payer who prints a wrong total is a business call, not a software one. Workspace roles govern invites, settings and the ledger connection rather than posting, so the check is the review step itself and there is no second approver. On QuickBooks the ledger can consume an unapplied credit before the document ever reaches us, which is a setting inside your own QuickBooks account, and we warn you while it is on.
3. What can it write to my ledger, and what can it only read?
"Which permissions does the connection request, so I know what's technically possible? And separately, which record types does the software create, change or delete? Can it touch an invoice, a credit note, or a customer record?"
Permissions settle what is impossible, whereas what the software chooses to write is policy, and policy changes with a release. Xero splits its permissions up, so a vendor can be locked out of your contact records by the platform itself. QuickBooks grants accounting access as a single permission, so every guarantee there rests on the vendor's own code rather than on a boundary Intuit enforces.
A good answer is an itemised list of what the software creates, changes and deletes, separating the guarantees the platform enforces from the ones the vendor chose. Ask about the writes you wouldn't think of, since attaching a file is a write against the record it attaches to, and applying a credit changes that credit's remaining balance. A weak answer says "we cannot do that" where the accurate sentence would be "we do not do that".
How to verify it
Two checks, both free, and neither one needs the vendor's cooperation. Read the consent screen when you connect, and note which permissions say view and which say manage. Then, once the first document has posted, open the ledger's own record of who changed what, History and Notes in Xero or the Audit Log in QuickBooks.
Our answer
On Xero the connection requests transaction and attachment write access, plus contacts read-only, so editing a customer record is impossible for us rather than merely disallowed. We create payments and batch payments, allocate credit notes, which changes a credit's remaining balance, and attach the remittance document to invoices and to the bank transaction, each its own setting. What we never do is create an invoice or change its amounts, dates or contact, though the transaction permission would allow it. The settings permission we request can write as well as read, and we only read from it.
On QuickBooks, Intuit issues a single accounting permission covering everything, so the scope is broader than what we use and there's no narrower one to request. There we create one payment per customer and attach the remittance document to it and to the invoices, each attachment its own setting. We also delete a payment we've just created when the credit it depended on didn't land as sent.
4. What happens after it posts something wrong?
"Assume it applies a payment to the wrong invoice. Walk me through the next ten minutes. Where do I undo it, does the undo happen in your software or in my ledger, and what's left behind afterwards?"
No amount of prevention covers every case, and what a vendor built for the ones their controls missed tells you whether the product has been run in anger. If the tool posts native ledger records you're left with an ordinary reversal your accountant already knows how to do, and if it keeps its own parallel state you're unwinding two systems that disagree.
A good answer is an unglamorous walkthrough of where the reversal happens and what the tool shows afterwards, so the document can't re-post without anyone noticing. A weak answer is "that does not happen", or a vague "you'd just fix it in Xero" with no account of what the tool does next, which usually means it still thinks the document is posted.
How to verify it
Do it in the trial, on a small payment. Post one against the wrong invoice on purpose, then reverse it in the ledger, removing the payment from the invoice in Xero or deleting it in QuickBooks. Then check three things: whether the ledger looks exactly as it did before, including the bank line's reconciliation status, whether the tool still thinks the document is posted, and whether you can reprocess it cleanly.
Our answer
RemitClear writes native records and nothing else. A payment we created is an ordinary Xero or QuickBooks payment, so undoing one is the operation your bookkeeper already knows, done in your own ledger, with no proprietary object left behind, and we built it that way because a tool that needs its own reversal screen holds state your accountant cannot see. We stop short of reversing a completed post for you, because deleting a payment out of a live ledger is a decision that belongs to the business. The document stays marked posted in RemitClear, holding its links to the records it created, and re-extraction and re-matching are closed off on it, so nothing can re-post over your reversal while you aren't looking. Putting it through again means uploading it a second time on purpose, and it's flagged as a duplicate when you do.
The principle underneath all four
All four questions come back to the same test, which is to judge the software by what is sitting in your ledger and your bank reconciliation afterwards rather than by what it said on screen.
One question comes before all four, and it decides whether this list applies at all, because AR automation covers two separate jobs and a product built to chase invoices will not match a payment however well it answers on price and security. Work out which job the vendor is in first, then run these four.
