Cash Application for ECI Spruce
Checks, lockbox files and ACH remittances read and matched to the open invoices in Spruce, the short pays and the payments spread across jobs included. The cash receipt batch is prepared for Spruce; exceptions wait for a person, and a person posts.
Collections & ARUpdated Oct 202620 ERPs
See it work on Spruce.
Click through the steps. Fictional data, in Spruce’s terms; the real thing runs on Spruce.
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 Spruce.
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 Spruce, 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 Receivables 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 Spruce’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 Spruce 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 Spruce: customer, invoice, amount applied, discount taken, reference. Your team reviews it and posts it. The next night Lunica reads Spruce and confirms the invoices closed.
How it connects to Spruce.
Lunica reads Spruce’s open items, the customer account and the day’s posted receipts through a read-only login to the Spruce SQL Server 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 Spruce on its own. The cash receipt batch goes back as a Spruce 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 Spruce?
No. It prepares the cash receipt batch, customer, invoice, amount, reference, and your team posts it. Lunica reads Spruce 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 Windows server inside your network, or beside ECI’s hosted Spruce, set up and maintained by Lunica. It reads ECI Spruce through a read-only login to the Spruce SQL Server database. There is no inbound connection from outside your network.
What does Lunica read in Spruce?
The customer account, open items and terms, purchase orders and receipts, the item record, quotes and order history, as each workflow needs them. Read-only, and only the rows a task is about.
Can it post to Spruce?
Nothing lands in Spruce without a person. What belongs in Spruce goes back as a Spruce import where one exists, or keyed by your team from what Lunica prepared.
What about our documents?
Invoice copies and scans keep living in Spruce document imaging. 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 Spruce version.
See it on your Spruce data.
Thirty minutes. We walk the workflow on Spruce data, then map it to yours.