Collection software that is not a recovery engine, a retry ladder, or a credit bureau
Almost everything sold under this name is one of three things: a ladder of messages that escalates on a timer, an engine that retries a card you already have on file, or a bureau that scores your customers. NoxOrigin is none of those and does not pretend to be. What it gives you is a prioritised outstanding list with a promised date on it — an ordered queue of who owes what, by when, decided by a rule somebody wrote down instead of by whoever shouts loudest. The queue is small, honest, and entirely yours.
Three products this is not, and one thing it is
The three things below are the reason collection software feels automatic. None of them exists here, and the fourth is what you get instead.
The dunning ladder: a schedule that sends messages and hardens the tone
There is no dunning sequence, no automated escalation, no step-2-after-step-1 logic, no stop rule, and no retry ladder. The system does not send anything on a timer and does not decide when the tone should change. Every reminder that leaves your office is one a person decided to send, and what was said and when is prose you wrote — there is no message history in NoxOrigin, because this platform does not send mail.
The retry engine: a card you already hold, charged again
There is no card on file, no auto-debit, no stored payment credential, no scheduled recurring charge, and no second attempt after a decline. NoxOrigin does not move money at all: a payment arrives because somebody arranged it, and it reduces an invoice only once a person allocates it. If you want a system that charges a card without asking, that is a payments product, and the receipt still has to reach the ledger by hand.
The credit bureau: somebody else’s opinion of your customer
There is no credit bureau, no credit score, no risk rating, no bureau export, no probability of payment, and no third-party credit check. An ageing bucket is today's date minus the invoice date, looked up in a table — a description of the past, not a prediction. Treat it as a description, because that is all it is.
What there is instead: a prioritised outstanding list with a promised date on it
Every open invoice, its derived outstanding amount, and a date you wrote beside it. Ordered by that date, so the first call is the promise you missed rather than the biggest number. No score, no automation, no campaign — a written rule, a column you filled in, and a list that can be checked line by line against the ledger underneath it.
A collection routine that ends in a document, or in a decision not to
Six steps. Every one of them is a person doing something on purpose, and step six has two endings — which is the part most products hide.
Fix the customer, because a queue is only as good as its rows
If the same customer sits on two records you have two outstanding lists, two ageing rows and two promises, and the person chasing may chase twice or forgive once. Detection flags the pair as merge candidates and a person reviews — merging is a setup decision, never automatic. Doing this first costs an afternoon; skipping it costs a write-off you cannot undo.
Let outstanding be derived, and stop typing it
Outstanding is invoice minus allocations, line by line, always re-derivable. The moment a figure is typed in it becomes a number that can disagree with the ledger underneath it, and a queue built on a typed number is a queue you cannot audit. Paid is a projection of allocations, not a stored flag, for the same reason.
Write the promised date against each open item, by hand
One date per outstanding item, entered by a person, meaning the date you told the customer and the date you will act on it. No promise-to-pay capture, no payment-plan record, no dunning schedule and no system suggestion — the date is a commitment someone made and owns. This is the one input the queue is built from.
Order the queue by the written rule, not by the loudest voice
Oldest promised date first, and when two are equal, then by amount. The system can sort a list by a column you filled in; it will not score, rank by risk, or promote the biggest number past a promise you broke. If the rule is wrong, change the rule — and know that you changed it.
When the money lands, allocate it deliberately
A payment is a separate record and it reduces nothing until it is allocated to an invoice. Where a single payment lands across several invoices is a decision with consequences, and NoxOrigin does not make it for you or spread it by date behind your back. An unapplied receipt is money you hold that has not reduced a single invoice.
Decide, per debt, whether it is being worked or written off
Worked means the promised date is live and owned. Written off means you stop, and the decision is recorded as a credit note against the invoice because that is the only thing that reduces what is owed. There is no auto-write-off at any age and no reason code — the reason is prose you write, and some debts are never recovered.
One customer, three invoices, and a queue that disagrees with the amount
Every figure below is constructed for this page so the arithmetic can be checked by hand. It is not a NoxOrigin result, not a customer’s account, and not a benchmark — there is no average time to pay in this page because we have no business quoting you one. Replace all of it with your own figures before drawing anything from it.
The three invoices
INV-11 raised 40 days ago for ₹60,000, nothing allocated against it, so outstanding is ₹60,000 − ₹0 = ₹60,000. INV-12 raised 32 days ago for ₹1,20,000 with ₹1,20,000 allocated, so outstanding is ₹1,20,000 − ₹1,20,000 = ₹0. INV-13 raised 9 days ago for ₹1,50,000, nothing allocated, so outstanding is ₹1,50,000 − ₹0 = ₹1,50,000. Total billed ₹60,000 + ₹1,20,000 + ₹1,50,000 = ₹3,30,000, total allocated ₹1,20,000, so total outstanding is ₹3,30,000 − ₹1,20,000 = ₹2,10,000, which is the same as ₹60,000 + ₹0 + ₹1,50,000. INV-12 is not an outstanding item and does not belong on the queue, and nothing marked it paid — paid is what the allocations say it is.
What the ageing report says about those invoices
INV-11 is 40 days old, so it lands in the 31–60 day bucket; INV-13 is 9 days old, so it lands in 0–30. Both numbers are just today's date minus the invoice date, looked up in a table. The older row is not a worse customer, and the bucket is not a probability — it is a description of how long the invoice has existed, which is why a queue built on it is really a queue built on age.
Now the promised dates, and the order they force
Against INV-11 you wrote a promised date 22 days ago; against INV-13 you wrote a date 12 days in the future. Sorted by amount, the queue is INV-13 first at ₹1,50,000 and INV-11 second at ₹60,000. Sorted by the rule you actually wrote — oldest broken promise first — the queue is INV-11 first, at ₹60,000, and INV-13 second. The system sorts by your column; it does not decide that the bigger number deserves the first phone call. That inversion is the entire product.
The payment that arrived and did not reduce anything
A payment of ₹90,000 is recorded. Until it is allocated it has touched no invoice, and outstanding is still ₹2,10,000 — money in the bank, unchanged on the ledger. Allocate ₹60,000 of it to INV-11 and that invoice’s outstanding becomes ₹60,000 − ₹60,000 = ₹0. The remaining ₹90,000 − ₹60,000 = ₹30,000 is unapplied, and total outstanding is now ₹0 + ₹0 + ₹1,50,000 = ₹1,50,000, which matches ₹2,10,000 − ₹60,000 = ₹1,50,000. Unapplied cash is a separate record from money that has reduced anything, and only the second one changes what the customer owes.
The same ₹90,000, allocated somewhere else
Allocate all ₹90,000 to INV-13 instead. INV-13 outstanding becomes ₹1,50,000 − ₹90,000 = ₹60,000, INV-11 is untouched at ₹60,000, and total outstanding is ₹60,000 + ₹60,000 = ₹1,20,000. The cash is identical, the total is different, and which customer statement is settled depends entirely on a decision a person made. Nothing here is spread by date or applied to the oldest invoice automatically; that is a real decision with a real consequence and it belongs to you.
The write-off, which is a decision and not an oversight
Continue from the state above, where INV-11 is settled and INV-13 stands at ₹1,50,000 outstanding, and decide to stop working it. There is no write-off automation, no automatic forgiveness at any age, no written-off flag, and no reason code. The only instrument is a credit note for ₹1,50,000 against INV-13: that invoice’s billed becomes ₹1,50,000 − ₹1,50,000 = ₹0, allocations against it are ₹0, so its outstanding is ₹0 − ₹0 = ₹0. Total outstanding is now ₹0 + ₹0 + ₹0 = ₹0, down from ₹1,50,000. Cash received for this customer did not move by a single rupee — ₹1,50,000 of outstanding disappeared because a person decided to stop, and the decision is the document.
What changes if the write-off follows a real recovery instead
Say ₹10,000 had come in against INV-13 and been allocated before you gave up. The same credit note for ₹1,50,000: billed becomes ₹0, allocations are ₹10,000, so outstanding is ₹0 − ₹10,000 = −₹10,000. The customer is ₹10,000 in credit, and unlike the line above that credit is backed by an allocation — it is real money you are holding. Identical document, opposite meaning: a credit with no allocation behind it forgives a debt, and the same credit with an allocation behind it converts part of a debt into a balance you owe back. The difference is visible in one field.
The split record, where one debt is shown as two customers
The same human is on record A with INV-11 and record B with a ₹45,000 invoice and nothing allocated. Two outstanding lists, two ageing rows, two promised dates, and one counterparty. Summed correctly it is ₹60,000 + ₹45,000 = ₹1,05,000 owed by one person — but displayed it reads as two, so the same customer can be chased twice in a week, or the ₹60,000 can be written off while the ₹45,000 is forgotten. Detection flags A and B as merge candidates and a person reviews the pair; merging is a setup decision and nothing merges automatically.
The figure this page will not give you
There is no collection rate, no average days-to-payment, no recovery percentage and no benchmark anywhere in this page, and we would not print one we cannot source from your own records. What a recovery rate is measuring depends entirely on who is in the denominator: a rate calculated over invoices you decided to pursue and a rate calculated over every invoice raised are two different numbers from the same ledger, and the flattering one is always the narrower denominator.
Where this is the wrong tool
A collections tool is judged by what it refuses to do without a human. Almost everything below can be automated into looking helpful while quietly making a commitment or a threat your business has not authorised.
There is no recovery engine, and that is deliberate
No dunning sequence, no automated escalation, no retry ladder, no card on file, no auto-debit, no credit bureau, no write-off automation, no legal escalation, and no third-party collection agency. Nothing in NoxOrigin chases, retries, scores, forgives or hands a file to an agency. Every one of those is a real product with a real owner, and stacking them onto a ledger that is supposed to be right is how an accurate invoice list ends up full of documents nobody can explain.
No statutory recovery, no legal notice, no lawyer workflow
NoxOrigin does not pursue statutory recovery, does not issue legal or demand notices, and has no escalation-to-lawyer path, no legal-hold concept and no agency integration. Recovery of this kind belongs to a recovery firm or a lawyer, who work under different rules and from different documents. The handover is a real step, and pretending a button in a ledger replaces it is the kind of claim that ends in a letter.
Paid is a projection, and there is no promise-to-pay or plan record
An invoice and a payment are different records; paid is derived from allocations rather than stored, and cash received without an allocation has not reduced anything. There is also no promise-to-pay capture, no payment-plan record, no arrangement tracker and no interest or late-fee calculation — the promised date is a date somebody typed, and if you need the arrangement itself on the record, it lives in a document you keep.
Nothing merges automatically
Merge is a setup decision. Detection flags candidate pairs and a person reviews them; there is no automatic merging, so a split record quietly splits the outstanding list, the ageing report and the write-off history exactly as thoroughly as it splits the contact.
This is not a tax or a statutory-filing product
NoxOrigin does not file GST returns or any other statutory return, does not determine how a credit note or a written-off balance should be treated, and does not issue tax invoices on your behalf. A credit note written to forgive a debt has a tax consequence, and that question goes to your chartered accountant — not to a field in this platform and not to us.
Reconciling the day's money is a setup conversation
Shift close and day-end reconciliation are assisted-setup maturity, not switches you flip in an afternoon. What is set up with you, and how quickly, is agreed during implementation rather than assumed by a button on this page.
Where the queue has to land
The promised date, the allocation, and the credit note you eventually write are all facts about one customer. If they cannot be traced to that record, the queue is just a list of amounts somebody felt bad about.
Run it on the plan that matches your customer count
Growth is ₹1,600/month or ₹15,000/year, includes a 30-day trial, 10 users, 50 active projects, and 10,000 contacts. The customer, the invoice, the payment and the allocation are part of the workspace rather than an add-on. These are NoxOrigin platform plans — NoxCRM, Nox-Billings and Nox-Tickets remain available as scoped custom deployments, quoted and priced separately, and none of them turns this into a recovery engine.
Debt collection and recovery questions
Is NoxOrigin collection and recovery software?
Not in the sense the word is usually sold in, and pretending otherwise would waste your time. There is no dunning sequence, no automated escalation ladder, no retry ladder, no card on file, no auto-debit, no credit bureau, and no write-off automation. NoxOrigin does not send a chasing campaign on a schedule, does not retry a card, does not score anybody, and does not hand a file to a collection agency. What it does hold is the customer, the invoices, the money that has actually arrived, and the queue you wrote down — which is a different and much smaller product from an automatic recovery engine.
What decides who gets chased first?
A rule you wrote, and a date you wrote on the list. Outstanding is not typed in and not scored: it is the invoice minus the payments allocated against it, so the number is always re-derivable. The queue is then ordered by the promised date you recorded against each outstanding item, not by its size and not by whatever the system thinks is risky. Put plainly: the software can sort a list by a column you filled in, and it will not decide what goes in the column. That is the whole difference between this and a scoring engine.
Can it chase the customer for me?
No. There is no scheduled ladder of reminders, no automatic tone escalation, no stop-after-N-times rule, and no promise-to-pay capture. What you send is a message you send, and the record of what was sent is whatever you wrote down — NoxOrigin stores no message history and sends nothing on its own. Nor is there a card-on-file or auto-debit: money arrives because a person arranged it, and it becomes an allocation because a person decided which invoice it lands on.
Can it recover money automatically?
No, and an automatic recovery engine is a different product with a different risk profile. Recovering money without a person deciding to is a collections decision, and it is one the platform will not make for you. If you want an engine that escalates, retries and recovers, buy one — and keep it separate from the ledger, because the moment cash lands in an account it has to be allocated by a person anyway before it reduces anything.
What happens to a debt I decide not to pursue?
You record the decision as a document, because a credit note is the only instrument here that reduces what a customer owes. There is no written-off flag, no write-off reason code, no collection-outcome record and no automatic write-off at any age. Some debts are never recovered, and that is a decision rather than an oversight — write it down as a credit note against the invoice and keep the reason in prose, because the credit note will not carry your reasoning for you.
Does it check my customer's credit or report to a bureau?
No. There is no credit bureau integration, no credit score, no bureau export, no risk rating and no third-party credit check anywhere in NoxOrigin. An ageing bucket is a date comparison — today's date minus the invoice date, looked up in a table — and it says nothing about whether this customer will pay. Treating a 45-day bucket as a risk signal is borrowing a statistic you have not earned.
Can it pursue the debt legally?
No. NoxOrigin does not do statutory recovery, does not issue legal or demand notices, and has no third-party collection agency and no lawyer workflow. Those belong to a recovery firm or a lawyer, who work from a different set of rules and a different set of documents. If a debt reaches the point where that is the next step, that is the moment to hand it over — not a feature to turn on here.
The same customer is on two records. What then?
You get two outstanding lists, two ageing rows and two promised dates, and the person doing the chasing has to notice. Merging is a setup decision, not a switch: detection flags the pair as candidates and a human reviews, and nothing merges automatically. A split record is expensive twice over — the same customer can be chased twice, and a write-off on one record can forgive money you still hold on the other.
Is paid a stored field I can sort on?
No. An invoice and a payment are different records, and paid is a projection of allocations rather than something stored on the invoice. A payment that has been received but not allocated has not reduced anything on any invoice, which is why the outstanding list can be right while the bank balance already shows the money. Paid is therefore something the system derives, not a status you maintain by hand.
Bring your worst outstanding customer.
We will build the outstanding list in front of you, show you exactly where every figure comes from, and then be blunt about which of the three products you actually need — this one, a recovery engine, or a lawyer.