ERPClaw 4.15: Tested the Way You Actually Work

Version 4.15 is live on every channel. There is no new screen to show you, and that is rather the point. This release is about money landing where it should, and about being able to prove that it did. Three parts of it are worth your time.

We test it the way you would actually use it

Software is usually tested by exercising every button. That tells you the buttons work. It does not tell you your books are right.

Before this release could ship, it had to get through a set of complete business scenarios, each one driven in plain business language from beginning to end: a customer short-pays an invoice, a recurring billing run turns into a real invoice, an invoice raised outside the billing flow gets attached to the period it belongs to, an order runs all the way to cash with corrections along the way, a deposit is forfeited and kept. Then a deterministic check reads the books that came out of the other end and decides pass or fail on the numbers, not on the screens.

Every scenario passed on the code we shipped, and the books-integrity rules held in all of them. That gate is the floor now. A scenario that ends with the wrong balance stops the release, whatever the buttons did.

The reason to care is that those scenarios are your Tuesday. They are not synthetic edge cases invented to keep a test suite busy. They are the awkward, ordinary things that happen in a real business and quietly break accounting software.

Write-offs, the way an accountant would do them

Two situations, both of which used to be tidier in theory than in practice.

The first is the short payment. Say a customer owes you $4,000, pays $3,850, and considers the matter closed. What you want is to record what they actually paid and write off the difference in the same movement, so nothing is left dangling on an invoice that will never be settled. That is now one step, taken as part of the payment itself:

“Record their payment against this invoice and write off the short amount.”

The second is bad debt. When you decide an invoice is not going to be paid, ERPClaw posts balanced bad-debt entries against that invoice, dated by the decision rather than by the original sale. The distinction is not pedantry. The loss belongs to the period in which you made the call, and quietly backdating it into a period you have already closed is how a clean set of books turns into an awkward conversation. Both write-off routes ask you to confirm before anything moves, and in the legal edition, writing off an invoice now moves the actual books instead of only changing a status.

Corrections you can see

If you run more than one company, the consolidation step that cancels out trading between them is now safe to run twice. It eliminates only what is new, so a second run does not double the adjustment. If an earlier repeat run left damage behind, the consolidated trial balance names the leftover rows instead of absorbing them quietly, a listing shows you exactly which rows they are, and removing them takes an explicit confirmation and records every removal.

Upgrades got the same treatment. A migration now declares whether it touches your data, and the ones that do write an audit-trail row for every document they change, inside the same transaction as the change itself. When an upgrade repairs something in your history, you can see precisely what it repaired.

Two shortcuts were retired rather than patched: a legacy elimination pair that posted group adjustments into operating companies’ own books and left them unbalanced, and two stock actions that could move quantity without a matching entry in the books. Both now decline and name the flow that does the job properly. A closed route is better than a quietly wrong one.

Underneath all of it sits a new always-on rule: every customer’s payment history has to agree with their open invoices minus any unapplied cash, exact to the cent, at all times. Around that, a run of repairs. Cancelling an invoice now releases the cash that was applied to it, so money stops being held against a document that has left the books. What a customer owes is no longer counted twice. Loan money reaches the books instead of vanishing into a swallowed error. A disposed asset posts its proceeds and its gain or loss to the right accounts rather than to depreciation. This is the same argument as our audit-ready books page, taken one step further.

PostgreSQL, verified

The supporting technical note. Every schema change, connection and catalog lookup now runs through a single seam in the code, and the module install path is verified against a live PostgreSQL server rather than against SQLite alone. PostgreSQL or SQLite remains your choice, the same software either way, and the reasoning behind that choice is written up in SQLite or PostgreSQL. MySQL is not supported, because the schema cannot be indexed properly there, and it now says so plainly instead of half-working.

FAQ

What happens when a customer pays less than the invoice?

Record the payment and write off the difference in the same step. The shortfall posts as a real bad-debt entry instead of sitting on the invoice as a balance nobody is ever going to collect.

Should a bad debt be dated to the sale or to the decision?

To the decision. ERPClaw dates a write-off by the day you decide the money is not coming, so the loss lands in the period where you made the call rather than in one you have already closed.

Do I need to do anything special to upgrade?

Run the upgrade. Where existing data needs repairing, the migrations do the repair and record what they changed, document by document, so nothing about the fix is invisible to you.

Can I run the consolidation more than once?

Yes. Elimination generation only eliminates new activity, so a repeat run does not double anything, and whatever an older repeat run left behind is reported to you and can be removed with an explicit confirmation.

What does this cost?

Nothing. ERPClaw is free and open source, self-hosted, and every part of this release is in it.