Payment plan calculations
The sale changed. The plan didn’t.
A refund, an added line, a cancellation. The change lands weeks after the fact, the plan recomputes forward, and the months already charged keep the arithmetic they were given — built on figures everybody now agrees were wrong.
Amortance is calculation software for platforms whose merchants finance their own sales and carry the balance themselves. It replays a payment plan from its first day against the order behind it — past periods included — and returns every figure with the rule, the inputs and the effective date it came from. Your platform keeps the customer, the money and the data. It returns the numbers and the reasoning — from inside your product, not beside it.
- The order is the principal
- The amount financed is the sum of the lines actually sold, not a number typed into a loan.
- Changes are events
- Each one carries the date it takes effect. Which date it is comes from your contract, not from the software.
- The plan is replayed
- Every payment is re-split against the balance that was really there, including the months already charged — so what is owed today moves, not just the explanation of it. Same inputs, same figures, on any machine.
Industries
Where this actually hurts.
The mechanism is the same wherever a merchant carries the paper; the events, and the defensible readings of each, aren’t. Two industries are written up so far. Each section carries the events that move a plan there, a worked example followed to the cent, and the same terms.
The offer
A calculation layer inside your platform, maintained for as long as you run it.
Not a report, and not a consulting engagement. The engine that answers what is owed and why, for every plan your merchants carry — embedded in your product, configured to your contract rules, and shipped with test vectors so your own team can prove it still agrees.
Status. The calculation core is public and runnable today — the worked examples in each section are computed by it, and a second implementation, sharing no code with it, reproduces every published figure, across every policy where the examples take both readings. What is in build is the productized layer: multi-tenancy, your event catalog, the API. The first partners’ catalogs decide what ships first, and I don’t publish integration dates I can’t hold.
Who. Built and run by Evgenii Agafonov — in consumer lending since 2022 as a developer and tech lead, on origination pipelines and microloans.
- Embedded
- One integration covers every merchant on your platform. The obligation stays inside your product; it returns the figures and the reasoning behind them.
- Maintained
- Contract terms change, state requirements change, your product changes. Keeping the calculation and its test vectors in step with all three is the job, not a favor.
- Off your support queue
- The support work that currently answers “how did you get this number” by reconstructing the history by hand in a spreadsheet.
- Verifiable, and not locked in
- Every figure can be reproduced outside my code — not only the balances but the repriced installments and the payoff date under each credit date. The calculation core and its test vectors are public under MIT, and the event catalog we agree is your document: the arithmetic and the rules of your own book stay yours whatever happens here.
How it starts
With a review of the book you already have.
You send an export of 20–50 existing plans. I replay each one against the rules your contracts actually state and return a per-plan comparison, including the periods already charged.
Why the first step is manual, and not an integration
- The rules are nowhere written down
- The contract says one thing, the code does another, and the two only diverge on particular events. An integration configured from assumptions returns confident wrong numbers. The review is where each event and its policy get agreed with whoever owns the numbers — and that document is what an integration is configured from.
- Nobody knows what it costs you yet
- I can show that the discrepancy exists and what a single event is worth. How often it happens across your merchants, how many support calls it becomes, how much your team already absorbs — no such figure is published anywhere, and I’m not going to invent one. The review measures the plans in the export and nothing past them: a result on the sample, not a rate across your book. If you want a rate, say so before the export and we pick the sample by a rule rather than by what is easy to pull.
- You may not need one
- If your own module already agrees with the contract on every plan in the export, that’s the answer, and it’s worth having in writing. Finding it out takes an export and nothing else.
- It costs an export, not a sprint
- No code, no credentials, no access to your systems. The work happens on my side first, and you check it against published test vectors before anything is embedded anywhere.
- The catalog is the point
- Writing your events down is most of the work behind an integration, and the first reviews exist to get it done: you get the comparison, I get the catalog the engine ships with.
Terms
- Delivery
- Ten business days from the agreed start.
- You provide
- Contract terms, the plan list, and the history of what changed and when. Anonymized is fine.
- You risk
- An export. No integration, no credentials, nothing to install.
- You get
- A comparison for every plan, the reason for each difference, and the rules of your book written down — which is also what an integration is later quoted from. The shape it arrives in, on synthetic data: dental, dealer.
- Your data
- The export is processed on my machine, never uploaded anywhere, and deleted once the review is delivered — or sooner, on request. Anonymized exports are preferred.
Check it yourself
None of this has to be taken on trust.
The complete input behind both worked examples is published, and beside them a short self-check you can run against your own module. A second implementation — written from the specifications, sharing no code with the engine — reproduces every figure they publish: the balances, the repriced installments, the payoff date under each credit date, 588 in all. The engine and the verifier are both MIT.
Reference implementations for reproducing the published examples; not servicing software for live accounts.
The engine, the two specifications and the verifier: engine.py, dental.json, bhph.json, verify.py. The command that runs them sits beside the worked example on each industry page.
Start here
Two sentences are enough.
What your merchants put on a plan, and what changes after the sale most often. Within a day you get back: whether the layer applies to the change you describe, what checking it on your own book would take, and a plain no when it doesn’t apply.