Match every invoice to every payment, and see the exceptions, not a summary.
The AR/AP Reconciler takes two sources (your ledger, and your bank feed or a partner statement), matches your receivables and payables within a tolerance you set, ties the whole thing back to the bank, and hands you the exact list of what is still open, short-paid, over-paid, or paid twice. It shows its work, because a reconciliation you cannot check is not a reconciliation, it is a guess with confidence.
Reconcile a period See a sample exception worklist
THE PROBLEM
Month-end reconciliation is where the errors hide. You match invoices to payments by hand (or in a spreadsheet that everyone half-trusts), you try to remember which bill already got paid, and you hope it all ties back to the bank. Most spreadsheets carry errors (the studies keep landing around 88 to 90 percent), and the ones in your AR/AP are the expensive kind, a payment applied twice, an invoice quietly written off, a number that never touched the bank at all. And now the newer tools want to hand you an AI that narrates your books, a paragraph that says it looks reconciled, which is exactly the thing you cannot put in front of an auditor or a board.
HOW IT WORKS
You give it two sources, your ledger (open invoices, open bills) and your bank feed or a partner statement (the receipts and payments). It matches AR invoices to receipts and AP bills to payments within a tolerance window you declare (penny-exact by default, loosened per customer as data, never as code), it dedups the double-applications, it ties the matched set back to the bank statement so the position reflects real cash, and it produces an AR and AP aging report on whatever is left. The matching is deterministic, it is arithmetic and rules, not a language model deciding how it feels about your ledger. Every exception it flags carries the two source rows that produced it, so you can check it, not just believe it.
WHAT YOU GET
A classified exception worklist instead of a green checkmark: - matched pairs, invoice to receipt, bill to payment, within your tolerance, - duplicates, the payment applied twice, the invoice imported twice, - a classified discrepancy list, unmatched receivable, unmatched payable, short-paid, over-paid, duplicate application, bank mismatch, one reason per row, - a bank tie-out, so the reconciled position reflects money that actually moved, - AR and AP aging, the open items bucketed by age (current, 30, 60, 90, 120+), so you know not just what is open but how stale it is, - the receipt, every flagged row keeps its two source rows attached.
WHO IT'S FOR
Small finance and bookkeeping teams closing the month by hand, fractional CFOs and bookkeeping firms running close across several clients, and any AR/AP team whose "we're reconciled" has to survive an audit or a board review. If your reconciliation currently lives in a spreadsheet nobody wants to defend, this is the mechanical version of it.
PRICING (the ladder)
- One close: a single reconciliation on your ledger and bank feed for a period, with the full exception worklist and aging. - Monthly: the reconciliation runs every period end and surfaces the new exceptions as your books move. - Multi-entity: for fractional CFOs and firms, the same run across several client entities, priced per entity.
(These prices are hypotheses we are validating, not commitments.)
THE PROOF (dogfood)
AYA runs its own AR/AP reconciliation through this exact line, its own invoices and bills against its own bank feed, matched, tied to the bank, aged. That is the honest dogfood, we close our own books with the thing before we sell it to close yours. And here is the part we will not dress up, right now the deliverable is built and validated as composition (the span is on disk, it scores as a real pattern, it composes three existing Anya capabilities), but the deterministic matching core underneath it is not wired yet, so there is no execution receipt to show, no witnessed clean close, not on our books or anyone's. reconciliation receipt to follow, once the core is wired
HONEST NOTE
Finance math has to be exact, so we would rather ship this late than ship a version that narrates. The composition and the policy (tolerance, field mapping, aging buckets, the discrepancy taxonomy) are done and are pure data. The one thing left is genuine code, a small deterministic reconcile-and-age core wired into a single handler, and until that exists and we have watched it tie out on real data, this product is honestly not yet runnable, it is blocked on that leaf. We are telling you that on the landing page on purpose, because the whole pitch is that you can check our work, and that starts here.
Reconcile a period
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*