Cash Application for Kerridge K8
Checks, lockbox files and ACH remittances read and matched to the open invoices in K8, the short pays and the payments spread across jobs included. The cash receipt batch is prepared for K8; exceptions wait for a person, and a person posts.
Collections & ARUpdated Oct 202620 ERPs
See it work on K8.
Click through the steps. Fictional data, in K8’s terms; the real thing runs on K8.
Check 4471 · $18,620.15 · Northline Drywall · Oct 14 · Stub: 2 invoices · 1 deduction noted · Read twice · both readings agree
Invoice 204317 · $12,300.00 · paid in full
Invoice 204331 · $6,640.15 · paid $6,320.15 · less $320.00 freight, per stub
Stub note: “freight billed in error, see Karen”
Payer matched: Northline Drywall · Karen Walsh, AP
A check stub scanned at the desk, read twice: payer, amount, invoices, and what the stub says.
The problem, as it happens in K8.
The morning’s mail is a stack of checks, a lockbox file from the bank, and six ACH deposits with the remittance advice in a separate email, or in no email at all. The clerk opens K8, pulls the customer account, and matches each payment by hand: this check covers three invoices and most of a fourth, that ACH is two jobs on one account, this one says PO 11874 on the stub and nothing else.
Cash that can’t be matched by noon goes on account, unapplied, and stays there. The invoices it was meant for still show open, so the aged debt report is wrong, the sweep calls a customer who paid, and the month-end unapplied balance is reconciled by someone who wasn’t in the room when the check came in.
How it works.
- 1
Every remittance is read
Checks and stubs scanned at the desk, the lockbox file from the bank, ACH advices from the inbox. A model reads each one twice: the payer, the amount, the invoice numbers, the PO or job references, any deduction noted on the stub.
- 2
Matched to the open invoices
Each payment is matched to K8’s open items on the account: exact amounts first, then invoice numbers, then PO and job references. A payment spread across two jobs is split; a short pay is matched to its invoice with the difference noted, not forced.
- 3
Exceptions wait for a person
Anything that doesn’t match cleanly, an amount that fits nothing, a payer K8 doesn’t know, a stub that names a disputed invoice, goes to a queue with what Lunica found and what it would do. The clerk decides each one.
- 4
The batch is prepared and a person posts
Matched payments become a cash receipt batch for K8: customer, invoice, amount applied, discount taken, reference. Your team reviews it and posts it. The next night Lunica reads K8 and confirms the invoices closed.
How it connects to K8.
Lunica reads K8’s open items, the customer account and the day’s posted receipts through a read-only login to the K8 database, nightly and again before the batch is prepared. Remittances come from the scanner at the desk, the lockbox file your bank drops, and the AR inbox; a model reads each document for the task at hand, never the book.
Nothing is posted to K8 on its own. The cash receipt batch goes back as a K8 import where one exists, or keyed by your team from what Lunica prepared, and a person posts it. Exceptions never go in the batch until the clerk settles them, and a short pay is applied as paid short, with the difference left open for the short-pay desk, never written off by Lunica.
What a week looks like.
- The morning’s checks, lockbox and ACH matched by the time the clerk sits down.
- Payments across jobs split to the right invoices, with the stub to prove it.
- Unapplied cash is a short list of real exceptions, each with a reason.
- Aging right the day the money arrives, so the sweep stops calling customers who paid.
Questions
Does it post the receipts to K8?
No. It prepares the cash receipt batch, customer, invoice, amount, reference, and your team posts it. Lunica reads K8 the next night to confirm.
How does it handle a check that covers part of an invoice?
It applies the check to the invoice as paid short and leaves the difference open, with the stub’s reason noted. The short-pay workflow picks it up from there; nothing is written off.
What about ACH deposits with no remittance?
Lunica matches by amount against the account’s open items and anything the customer sent to the AR inbox. If nothing fits, or two things fit, it waits in the exception queue for a person.
Does it read our lockbox file?
Yes, in the format your bank sends it. The file is read for the day’s payments; nothing is pulled from the bank beyond what your team drops in.
Does it take early-pay discounts into account?
Yes. An account with a discount term that pays inside the window is matched net of the discount, and the discount is a line in the batch for your team to accept or refuse.
Where is the scanned check kept?
With the batch line, filed against the account and the invoices it paid, so the question six months from now has the image beside the answer.
Does it need a server?
Lunica runs on one server inside your network, or beside KCS’s hosted K8, set up and maintained by Lunica. It reads Kerridge K8 through a read-only login to the K8 database. There is no inbound connection from outside your network.
What does Lunica read in K8?
The customer account, open items and terms, purchase orders and receipts, the product record, quotes and order history, as each workflow needs them. Read-only, and only the rows a task is about.
Can it post to K8?
Nothing lands in K8 without a person. What belongs in K8 goes back as a K8 import where one exists, or keyed by your team from what Lunica prepared.
What about our documents?
Invoice copies and scans keep living in K8’s document management. Lunica reads them when a workflow needs one and never writes to them.
The same workflow, on another ERP.
Cash Application is written for every system on the list. You’re reading the K8 version.
See it on your K8 data.
Thirty minutes. We walk the workflow on K8 data, then map it to yours.