An invoice asks for money. A payment is something that happened. Keeping those as two records is what lets a business know, on any day, who owes what and since when — rather than reconstructing it at month end from a bank statement, a spreadsheet, and somebody’s memory of which client said the transfer was coming.
NoxOrigin raises GST invoices, records full and partial payments against them, records payment promises with a date, and reads receivables by client and by age. It does not chase customers for you, and this page is as clear about that as it is about what it does.
Most collection failures are not disputes about the amount. They are failures of record. The invoice, the bank credit, and the client’s own recollection are three different stories, and the only person who can adjudicate between them is often the person who raised the invoice in the first place. The money is not missing; the version of events is.
That is why this page is about the invoice lifecycle rather than about getting paid faster in the abstract. If the record is right, the conversation is short. If it is not, the conversation is about reconstructing the past, which is a much worse thing to ask a client for.
The business knows a large amount is unpaid and has no way to order it, so the easy invoices get chased and the awkward one — the biggest one — gets postponed every month until it is old enough to be uncomfortable to raise.
A transfer lands with no reference, gets posted to nobody, and resurfaces at month end as a difference that everyone present is confident is not their fault. The client believes they paid. The record says otherwise. Both are correct, because there are two records.
'It should come in next week' is the most common state of an unpaid invoice in a service business, and it is the least durable. Without a date attached to the commitment, the follow-up has to wait for somebody to remember, and remembering is exactly what stops happening under pressure.
Two files, two totals, and a monthly argument about which one is right. The reconciliation is not difficult arithmetic — it is the disagreement that costs the evening, and it recurs because both files are maintained by people who each believe theirs is the current one.
Six states, each one a record rather than a status somebody remembers updating. The balance at every step is derived from the invoices and the payments, so it can always be traced back to what produced it.
The example below is arithmetic, not a NoxOrigin figure and not a result from a customer account. Replace every number with your own before drawing any conclusion from it.
Example — replace these figures with your own. An invoice is raised for ₹1,18,000 inclusive of GST. Three payments are recorded against that invoice: ₹40,000, then ₹50,000, then ₹10,000. The outstanding balance derived from those records is ₹18,000, and the ageing reads the invoice by the date it was raised rather than by the date of the most recent payment. Nothing was rounded, adjusted, or written off, so the ₹18,000 is a balance with a complete history behind it — and the conversation with the client can start with the actual position instead of a reconstruction of it.
The same reasoning works in the other direction. If a payment is recorded against the wrong invoice, the fix is a correction on a record with an audit entry, not an edit to a total that quietly absorbs the difference. That is the practical difference between an outstanding list and a bank statement with notes.
If you want to see the arithmetic on your own numbers before you commit to anything, the receivables ageing calculator runs the same buckets against figures you enter, and the payment collection tracker template is the spreadsheet version of the same list for teams still deciding.
This is not a collections service. There is no scheduled reminder ladder, no automatic late-fee calculation, no retry sequence, no recovery-fee model, and no escalation to a collections agency or a legal process. There is also no bank-statement matching and no gateway settlement reconciliation — that belongs to your payment provider and your accounting package.
What it does give you is a list with owners, ages, and dated promises, which is the part that usually fails. A system of record that holds commitments is not a system that enforces them, and we would rather you hear that here than discover it in month three.
Creating a quote, creating an invoice, recording a payment, and reading commercial reporting are separate permissions. An administrator who maintains customers and catalogs does not need the permission that records cash, and a delivery role does not get it by default.
Audit entries record the sensitive actions, so ‘who recorded this payment and when’ has an answer. On a counter, staff can sign in with a PIN tied to their own person record rather than sharing one login, so a shift’s actions are attributable to a person. See how roles and permissions are decided.
Because they are different facts with different shapes. An invoice is a request for an amount, issued on a date, with terms. A payment is an event that can be partial, late, split across several transfers, or received months after the invoice was raised. Collapsing them into one row is how an outstanding balance quietly becomes wrong and stays wrong: the invoice total gets edited to match what arrived, and the history of what was actually owed disappears.
Yes, and partial payments are recorded against the invoice rather than rounded away. Each payment carries its own amount, date, and method, and the balance is what the records say is left — not what somebody remembers. A payment promise can also be recorded with a date when the client has committed but not yet paid, so the follow-up has something concrete to refer to instead of a vague recollection of a phone call.
No. There are no scheduled dunning sequences, no automatic late-fee calculation, no retry ladder, no recovery-fee model, and no escalation to a collections agency or a legal process. What it does is give collection a list with owners and dates — an outstanding record, an age, and a promise with a date attached. If the problem is a client who does not answer anyone, that is a commercial and contractual problem, and a screen will not fix it.
It shows what is outstanding per client and how long it has been outstanding, so the question changes from 'how much is unpaid' — a total nobody can act on — to 'who owes what, and since when'. The oldest invoice stops being buried inside an average that looks acceptable because everything else is current. It is an operational read of your invoices, not a statutory ageing computed under an accounting standard, and it is not a period close.
Recording a payment is its own permission, separate from raising an invoice, and both are separate from reading commercial reporting. An administrator who maintains customers and catalogs does not need the permission that records cash. That separation is the practical point: the question 'who recorded this payment, and when' should have an answer, and audit entries record sensitive actions so it does.
No. Recording a payment is a deliberate act against a known invoice. Bank-statement matching, gateway settlement files, chargebacks, and payout reconciliation belong to your payment provider and your accounting package, and pretending a business platform does that work would be misleading. What NoxOrigin does is make the recorded payment the single fact that the outstanding balance is derived from, so there is one version of the balance rather than three.
Starter is ₹800 per month or ₹8,000 per year with 3 users, 10 active projects, and 1,000 contacts. Growth is ₹1,600 per month or ₹15,000 per year, includes a 30-day trial, and is the plan that includes Razorpay payment links against an invoice — usually the right starting point for a business that invoices regularly. Agency is ₹5,000 per month or ₹48,000 per year for teams running several workspaces.
Bring the client you are least sure about. We will show you how NoxOrigin turns that uncertainty into a named invoice, a recorded payment, a dated promise, and an ageing position you can defend.