One of them did. This is what that produced: reading that waits for a human, duties that stay separated under pressure, a match gate that blocks rather than warns, and payments that re-check themselves in the seconds before money leaves.
Most AP automation is sold on the promise that invoices process themselves. That promise is exactly what a Controller is accountable for when it goes wrong — because a bill that was created, coded and queued without a person reading it is a bill nobody can honestly say was reviewed.
PayCure inverts the default. Documents arrive and stay unread. When someone chooses to read one, AI extracts the header and line data and stages a draft for review. The machine does the typing; the person does the deciding.
On the read allowance. Plans include 3,000 AI document reads per subscription year, shared across bills, credit memos and vendor documents. Because reading is on request, the allowance is spent on documents you chose to process — not on every piece of spam that reaches the inbox.
Payment fraud against mid-market finance teams rarely looks like fraud. It looks like a familiar vendor, a plausible amount, and a short note explaining that the bank details have changed. It succeeds because it arrives inside a normal workflow and gets a normal approval.
PayCure screens every bill before it reaches an approver. The checks are deterministic rules, not a model that learns — which means they behave identically every time and can be explained to an auditor line by line.
Screening bills is a second line of defence. The first is refusing to create a payable vendor whose bank details were never validated and whose name was never checked against a sanctions list.
PayCure uses a single vendor form across all three onboarding routes — manual entry, AI-assisted capture, and vendor self-service. Three paths, one set of validations, so no route becomes the soft one.
Deep where it counts, honest everywhere else. Six markets get true local-rail checksum validation. Everywhere else is covered by IBAN or SWIFT structure validation — real coverage, described accurately rather than as "any currency, anywhere."
Separation of duties is easy to write into a policy document and hard to keep alive in a five-person finance team during a close. The moment someone is on leave, the practical answer is usually to let one person do both halves "just this once" — and that exception is where losses happen.
PayCure enforces the separation in software. Each control can be switched off deliberately, thresholded by amount, or overridden with a written reason — but never bypassed silently.
| Control | What it stops |
|---|---|
| Enter ≠ approve | Keying a bill and approving your own entry |
| Approve ≠ pay | Approving a bill and releasing its payment |
| Onboard ≠ approve vendor | Creating a payee and activating it yourself |
| Change ≠ verify bank | Altering bank details and confirming them alone |
| Issue ≠ reverse credit | Issuing a credit memo and reversing it unseen |
| + four further controls, each configurable | |
Delegation transfers real authority. When a Controller delegates before leave, the delegate inherits their approval authority for the delegation period — bills route to the delegate rather than waiting — and authority reverts automatically when it expires. No stuck approvals, and no shared password.
Most systems that advertise three-way matching produce a warning. The approver sees a yellow flag, recognises the vendor, assumes the difference is a freight line, and approves. The control was present and made no difference.
In PayCure a failed match blocks approval. To proceed, the approver must write a reason, and that reason is audit-logged permanently against their name. It takes ten seconds — but it converts an ignored banner into a decision someone owns.
The quiet risk in most AP systems is the edit. A posted bill is amended to fix a coding error, a paid invoice is voided and re-entered at a different amount, and the record of what actually happened is gone. Nothing looks wrong afterwards — which is precisely the problem.
In PayCure, posted documents are immutable at the database level. Not discouraged by permissions; not possible. Corrections are made by issuing a reversing document, and the reversal's amount is derived from the original rather than typed by a person who might mistype it.
Why derived rather than typed. A reversal keyed by hand can be keyed wrong — and a wrong reversal against a paid bill is one of the hardest errors to find, because both documents look individually reasonable. Deriving the amount from the source removes the opportunity entirely.
What this gives you at audit. Every state a document passed through is still queryable: what it said when it was approved, who approved it, what changed afterwards and why. You are never reconstructing history from memory or from a backup.
The most expensive window in accounts payable is the gap between a payment being scheduled and the funds actually moving. Bank details can change in that window. An amount can be wrong in that window. Once the money has left, everything is recovery rather than control.
PayCure puts three deliberate checkpoints in that gap — and refuses to offer batch payment, because paying fifty bills with one click is how a wrong amount leaves without anyone seeing it.
No batch pay, deliberately. This is a decision, not a missing feature. Bills are scheduled and released individually so that each amount is seen by someone. A Controller will recognise the trade-off — slightly more clicking, dramatically less exposure.
Vendors, bills, purchase orders, approvals, receipts and payment history are held in PayCure and stay there. A company can run its entire AP and procurement function here with nothing else connected — nothing is disabled, degraded or half-functional without an integration.
If QuickBooks Online is already part of your stack, connect it and the two stay in step without re-keying. That is the one integration available today, and we will describe any others as roadmap until the day they are live.
Requisitions with dimension enforcement, blanket POs with not-to-exceed caps, adverse-change amendment control, a no-login vendor portal, and receiving that blocks over-receipt past your tolerance. Built, shipping, and licensed separately.