Every vendor demos well, because a demo is a document somebody chose in advance. You are 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 missing on purpose: procurement already asks those. These four are what a polished demo can hide. They work whether the vendor calls the category remittance processing or cash application software. Two smaller checks: 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 a per-field number computed on documents the vendor chose. Straight-through rate is a per-document number your workflow produces. 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. The denominator is where the evasion lives: is that a share of fields, of lines, or of whole documents?
A good answer is a document-level rate with its denominator stated: every document from live customers over a stated window, plus an account of what the tool holds back even when it is confident. A weak answer is a bare percentage with no unit attached, or one that counts every document a person opened and approved unchanged. A tool that posts everything scores full marks and has no fail-safes.
How to verify it
Do not accept the number, generate it. Run a fortnight of your real documents through a trial and count three buckets: posted with nobody opening them, opened and approved unchanged, edited. The third bucket is the only one that predicts your workload, and it is the one vendor figures fold into the second.
Then split that bucket by payer. Exceptions concentrated in one or two formats are worth raising before you sign; spread evenly, they mean the tool is not reading your document class.
Our answer
We publish a match rate, and its unit is the remittance, not the field and not the line: 99 per cent across standard remittance formats, with anything the matcher is unsure about flagged for your review. Each document carries one verdict, however many lines it has. It is a match rate and not 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. 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 do not sum to the total printed on the document. And a credit on it cannot be fully applied against anything open. In each case, does it post anyway, adjust something to balance, or stop and tell me?"
All three exist, and the choice separates software that removes work from software that moves it to whoever does the bank reconciliation. Posting anyway leaves a bank line that will not reconcile. Adjusting silently is worse, because the ledger balances while the error stays invisible until somebody queries an invoice quietly part-paid months ago. Stopping costs a minute now 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 for a tool that parks the unexplained difference in a suspense or clearing account: the ledger then balances and finding the problem becomes 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 nothing open is 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 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 to fix. Anyone in your workspace can override a total mismatch and post anyway, because a payer who prints a wrong total is a business judgement, not a software one. Workspace roles govern invites, settings and the ledger connection rather than posting, so the check is the review step itself rather than a second approver. On QuickBooks the ledger can consume an unapplied credit before the document ever reaches us. That 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 is 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. What the software writes settles what is merely policy, and policy changes with a release. Xero splits its permissions, so a vendor can genuinely be locked out of your contact records. QuickBooks grants accounting access as a single permission, so there every guarantee is the vendor's own code rather than 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 would not think of: 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 is "we cannot do that" when the accurate sentence is "we do not do that".
How to verify it
Two checks, both free, neither needing the vendor's cooperation. Read the consent screen when you connect, and note which permissions say view and which say manage. Then, after the first posted document, 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, though 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 is 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 have just created when the credit it depended on did not 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 is left behind afterwards?"
Prevention always has a residual, and what a vendor built for the case their controls missed tells you whether the product has been run in anger. A tool posting native ledger records leaves you an ordinary reversal your accountant already knows. A tool keeping its own parallel state leaves you unwinding two systems that disagree.
A good answer is an unglamorous walkthrough: where the reversal happens, and what the tool shows afterwards so the document cannot silently re-post. A weak answer is "that does not happen", or a vague "you would 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 deliberately against the wrong invoice, then reverse it in the ledger: remove the payment from the invoice in Xero, or delete it in QuickBooks. Then check three things. Does the ledger look exactly as it did before, including the bank line's reconciliation status. Does the tool still think the document is posted. And can you 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. That is deliberate: 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 quietly re-post over your reversal. Putting it through again is a deliberate re-upload, flagged as a duplicate.
The principle underneath all four
Every question here has the same test inside it: judge the software by what is sitting in your ledger and your bank reconciliation afterwards, not 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. Establish which job the vendor is in first, then run these four.