Credits Belong in Your Books. Not in a Spreadsheet.
.png)
Credits Belong in Your Books. Not in a Spreadsheet.
When a vendor sends you a rebate or SLA credit, the standard workflow looks something like this: the credit arrives, there's no bill to attach it to yet, so it goes into a spreadsheet. It sits there until the right bill shows up—and until it does, your AP Aging is off, your outstanding payables are off, and your books are off. You don’t know what you owe because your books don't reflect what you actually owe.
The same problem exists on the AR side. Credit memos used to be a one-size-fits-one deal: one credit, one invoice, no partial application, no many-to-one. Need to unapply a credit memo? Delete it and start over. Tracing where a credit went meant manually cross-referencing across multiple screens.
Neither of these is a niche edge case. Both are problems finance teams deal with every single month.
Two Birds, One Launch
We built these two features together because the problem is the same on both sides of the ledger: credits don't arrive on a clean schedule, and your system should handle that.
Vendor Credits lets you record a vendor credit the moment it arrives—no bill required. When you're ready, apply it fully or partially, to one bill or to many, and track everything in one place with a clean status.
Credit Memos give your AR team that same flexibility: one credit memo to multiple invoices, multiple memos to one invoice, carry remaining balances forward, and unapply without deleting anything.
How It Works
Record → Apply → Done.
On the AR side: a customer returns part of an order. Instead of voiding a credit memo and starting over, you apply it partially to one invoice and carry the remaining balance forward to another. If something was applied incorrectly, just unapply it—the audit trail stays intact either way. The full history of where a credit went lives directly on the credit memo record.
Why This Works the Way It Does
The reason credits update everywhere instantly, and not in a nightly batch or at period end, is that Rillet's GL is real-time. When a credit is applied, the accounting entries post at that moment. No reconciliation step at month-end, because the books were already accurate when the credit landed.
In practice: a credit that arrives on April 3rd is in your books on April 3rd. Your AP Aging on April 4th reflects it. Nobody has to remember to update a spreadsheet. Nobody has to reconcile anything at close.
This is the same foundation behind Continuous Close. Your books are always current, so month-end isn't a process you run; it's just the state your books are in. Vendor Credits and Credit Memos are another part of making that real.
What's Coming Next
A few things are still in progress: the ability to choose which period a credit lands in (useful when a credit arrives after close has already started), bulk import for vendor credits, automatic syncing of unapplied credits from Ramp, and expanded API access.
Every credit, on every side of the ledger, should live in your system—not in a tab you have to remember to check.

.png)

.png)
.png)