Expense tracking that is a Nox-Billings capability, not a plan — with no receipt OCR, no card feed, no bank feed, no policy engine and no approval routing
The general answer to “what is expense tracking” is on the expense tracking page. This page is the narrower question: who approves a claim, and how does a claim become money? Two facts decide whether either is possible. Expense tracking is a Nox-Billings capability. Commerce carries purchasing and stock, but not expense claims or approvals, so a platform plan does not cover this side of the boundary. And there is no timesheet and no payroll to feed a claim from, so an expense has to stand on its own evidence — the document someone is holding — rather than on hours. There is no receipt OCR, no corporate-card feed, no bank-feed import, no expense policy rule engine and no automated approval routing here, and the reason is not that they are unfinished.
Two boundaries before any feature, and what you get instead
The first boundary decides whether you can buy this at all: expense tracking is Nox-Billings, so no platform plan covers it. The second decides what kind of product it is: without a card feed, a statement feed or an OCR engine, a claim is entered by a person and accepted by a person.
Expense tracking is a Nox-Billings capability. Commerce has purchasing, but not expense claims
Expense capture, categorisation, reporting and the money that follows are Nox-Billings features. Nox-Billings is a scoped custom deployment, quoted and priced separately against your own configuration. No NoxOrigin platform plan includes expense tracking, and the platform plan price is not a way to buy it. Commerce is a separate area again, and a platform plan does carry its purchasing and stock — but that is buying and inventory: there is no expense claim, no approver and no reimbursement anywhere in it.
The approval, and who performs it
There is no automated approval routing, no expense policy rule engine, no threshold band, no multi-step chain, no delegated approver and no escalation timer. A named person accepts or rejects a claim, and the record holds their name against it. This is the whole control: a person who can be asked, six months later, why a claim was allowed.
The machine readers, and all four of them are absent
There is no receipt OCR, no corporate-card feed, no bank-feed import and no automated approval routing. We hold no bank connection and read no statements. Every figure in an expense record arrived because a person typed it from a document they were holding, which makes the record slower to build and much harder to argue with.
What there is instead: the claim, its document, the name, and the payment
A claim with the spend categorised and a date. The document behind it, held by a person. The name of the person who accepted it. The payment recorded as a separate record and allocated, with the outstanding balance following. Because paid is derived from allocations rather than stored as a flag, an unallocated reimbursement is money that has arrived and not yet reduced anything — which is the most common way an expense register quietly stops agreeing with the bank.
A claim routine from a document to an allocated payment
Six steps. Step five is the one that goes wrong most often: a claim and a payment are different records, and a reimbursement that was never allocated has not reduced anything, however confident the person who recorded it felt at the time.
Decide the categories and the person who accepts each, and write them down
A category without a named owner is a suggestion. What makes the record useful later is that every spend under a category was accepted by a person you can name, on a date you can read. Two people, one claim, and a month-end question is a conversation. One named acceptor per category is a record.
Enter the claim from the document, and keep the document
A person reads the fare, the meal, the stay — or the invoice line — and enters it with its category and date. NoxOrigin does not read the receipt, does not extract the amount and does not import a card feed, so the claim is worth exactly what the document behind it is worth. Losing the document makes the claim an assertion, and an assertion in month nine is not a control.
Put it in front of the person who accepts spend, and record that they did
Not routed, not escalated, not tested against a rule. Forwarded, read, and marked by a person. The value of the record is not that the approval happened — it is that the claim and the acceptance are the same line, so nobody has to reconstruct who agreed to what from a message thread.
Reject rather than adjust, when the claim is wrong
A claim corrected into shape before it is accepted becomes a claim nobody can audit, because the number and the reason no longer match. Rejecting keeps the rejected claim in the record with the person who rejected it, and a repeated rejection is a policy conversation rather than a mystery.
Pay the claim as a payment, and allocate it
The claim is an assertion that money is owed to somebody. The payment is a record that money moved. They are different records, and paid is a projection of allocations rather than a stored flag — so a reimbursement recorded on Friday and never allocated has not reduced anything, and the balance your owner reads is wrong until somebody allocates it. This is the single most common reason an expense register and a bank statement stop agreeing.
Read the accepted claims against the project they were spent on
The cost lands against the same project as the work, so the comparison of quoted value against actual spend is between two records you already hold. What it is not is a rate per hour, because NoxOrigin has no timesheet record and no payroll module. A fixed fee absorbs the expense by design, and the conversation that should follow is a person repricing the next one.
One trip at ₹6,000, one claim at ₹18,000, and a month where ₹6,000 happened twice
Every figure in this section is constructed for this page so the arithmetic can be checked by hand. It is not a NoxOrigin result, not a customer’s record, and not a benchmark. The 18% GST appears only so the addition can be verified; it is not a tax position, and NoxOrigin does not file GST returns or any other statutory return. Nothing here is a policy compliance rate, a rejection rate, an average claim size or a spend per employee, and this page publishes none of those.
The claim a person enters from a document
A constructed trip: a fare of ₹4,000, meals of ₹800 and a stay of ₹1,200, which is 4,000 + 800 + 1,200 = ₹6,000. GST at 18% is 6,000 × 0.18 = ₹1,080, so the document total is 6,000 + 1,080 = ₹7,080. Checked the other way: 6,000 × 1.18 = ₹7,080. The expense claim is ₹6,000, not ₹7,080 — the tax element is not the spend, and treating the two as one figure is the most common arithmetic error in an expense register.
The decision, made by a person and recorded as one
There is no rule engine to test ₹6,000 against and no routing to send it anywhere. A named person reads the claim, accepts it, and their name is held against it. Suppose the threshold that person applies is ₹10,000 written on the wall of the office: this claim at 6,000 is below it, and it is still read by a person. A written rule a person applies is a control; the same rule applied by software would have removed the name from the record, and the name was the point.
The second claim, three times the first
A different person claims ₹18,000, which is 6,000 × 3 = the first claim exactly. Above the same ₹10,000 threshold, so this one needs a conversation rather than a nod. Across that week the two claims total 6,000 + 18,000 = ₹24,000, and GST at 18% on the second is 18,000 × 0.18 = ₹3,240, giving a document total of 18,000 + 3,240 = ₹21,240. What NoxOrigin records is two claims, two acceptors, two dates — and it will not tell you the second was three times the first, or flag it as unusual, because that judgement is yours to make.
How the claim becomes money, in two separate acts
The ₹6,000 claim is an assertion that a person is owed money. The reimbursement is a record that money moved, and it is a different record from the claim. Paid is a projection of allocations rather than a stored flag, so a reimbursement entered on Friday and never allocated against the claim has not reduced anything — the outstanding figure your owner reads is still ₹6,000, and nothing on the screen will say why.
The same receipt, claimed again the following month
The same ₹6,000 document is submitted a second time, so the month carries 6,000 + 6,000 = ₹12,000 against a trip that cost ₹6,000, and 12,000 − 6,000 = ₹6,000 of the same money counted twice. Nothing in NoxOrigin compares an incoming claim against previously paid claims and warns you, because duplicate detection flags candidates and a person reviews them; the merge policy is a setup decision and nothing merges on its own. A resubmitted receipt is caught by somebody reading the record, which is a weak control and an honest one.
The same cost, read against the project it was spent on
Suppose both accepted claims are charged to a project quoted at ₹3,00,000. The recorded cost against that project is ₹24,000, which is 3,00,000 − 24,000 = ₹2,76,000 remaining against the quote. As a share: 24,000 ÷ 3,00,000 = 0.08, so the recorded cost is 8% of the quoted value, and 2,76,000 + 24,000 = ₹3,00,000 checks out. It is a comparison of two records, not a margin rate — because there is no timesheet and no payroll here, the ₹24,000 cannot be divided by the hours behind it.
What the fixed fee does to those two claims
The quote is ₹3,00,000, the accepted expense against it is ₹24,000, and a fixed fee absorbs that cost by design — the fee is the whole point of a fixed fee. No NoxOrigin record can then show how many hours produced the other ₹2,76,000, and none of the ₹24,000 can be expressed as a rate per hour. The correct conclusion is not that the project lost money; it is that the expense is evidence and the price was a decision, and they are the two halves of this page.
The figures this page will not give you
There is no policy compliance rate, no rejection rate, no average claim size, no spend per employee, no cost per project hour and no expense-to-revenue ratio anywhere on this page. Each would be a ratio against a denominator chosen after the result is known, and a spend ratio with no timesheet behind it has no honest denominator at all. Two quite different compliance rates can describe the same month depending on which claims were counted, which is why we will not print one here.
What was asked for, and the honest answer
If the first six rows apply to you, an expense management product is the right category and no plan on this site changes that. The rest is what Nox-Billings does with a claim a person entered and a person accepted.
| What a buyer asks for | In NoxOrigin |
|---|---|
| Record an expense claim and categorise it | Yes, in Nox-Billings. Expense tracking is a Nox-Billings capability, and Nox-Billings is a scoped custom deployment priced separately from any NoxOrigin platform plan. |
| Approve claims against a written policy | By a person, not by a rule. There is no expense policy rule engine, no per-category limit and no out-of-policy flag, so the record holds who accepted what rather than a compliance score. |
| Route approvals automatically | No. There is no automated approval routing, no multi-step chain, no delegated approver and no escalation on a missed deadline. A person forwards, reads and accepts. |
| Read the receipt and create the claim | No. There is no receipt OCR, no invoice extraction and no photograph-to-claim flow. A person enters the figure from the document they are holding. |
| Import a card feed or a bank statement | No. There is no corporate-card feed and no bank-feed import; we hold no bank connection and read no statements. Payments are recorded and allocated by a person. |
| Compare spend against a budget | No. There is no budget record, no variance-to-budget report and no forecasting of spend. Accepted claims are readable per category and per person. |
| Turn a claim into money | Yes, as a separate record. A payment is a different record from the claim it settles, and paid is a projection of allocations — so an unallocated reimbursement has not reduced anything yet. |
| Read the accepted cost against a project | Yes. The cost sits on the same project as the work, so quoted value and recorded spend are two records you can compare. It is not a rate per hour, because there is no timesheet and no payroll. |
| Handle a scope change funded by a claim | As a new quote on the same project. There is no change-request record, no milestone or deliverable record, no contract editor and no e-signature, and the first quote is never overwritten. |
| Confirm the tax treatment of the spend | No. NoxOrigin does not file GST returns or any other statutory return and does not determine whether a cost is allowable or how input credit should be treated. That is your chartered accountant’s question. |
Where this is the wrong tool
Spend management software is judged by what it refuses to imply. The list below is the set of things a reader is most likely to assume are present because the page title sounds like they are.
Nothing here reads your receipts
No receipt OCR, no invoice extraction, no photograph-to-claim flow. The amount in a claim is a person’s reading of a document. If your requirement is a scan at the counter and a finished claim, that is a different product.
Nothing here talks to your bank or your card
No corporate-card feed, no bank-feed import, no statement parsing, and we hold no bank connection and read no statements. If auto-matching a card feed to claims is the reason you are here, this is the wrong product and we would rather you know it now.
Nothing here decides whether a claim is allowed
No expense policy rule engine, no per-category limit, no receipt-required flag, no out-of-policy warning, no compliance score. Your policy is a document people read; the record holds who accepted what.
Nothing here routes the approval for you
No automated approval routing, no multi-step chain, no delegated approver and no escalation on a missed deadline. A person accepts the claim, and the record keeps their name. That is slower than a rule and considerably easier to defend.
Nothing here divides the cost by the hours
No timesheet record, no time tracking and no payroll module, so an expense cannot be turned into a rate per hour or a cost per person-minute. Expense is a figure against a project; a margin is a comparison of two records, not a rate.
An invoice and a payment are different records, and paid is a projection
Money received reduces nothing until a person allocates it. Paid is derived from allocations rather than stored as a flag, which is why a reimbursement sitting unallocated is invisible in the balance and why an unmanaged allocation queue cannot be trusted.
This is not a tax product
NoxOrigin does not file GST returns or any other statutory return, and does not determine whether a particular expense is allowable, how input credit should be treated, or how a correction should be recorded. That question belongs to your chartered accountant. The 18% used on this page is arithmetic, present so the example can be checked by hand.
Expense tracking is scoped Nox-Billings work, so the platform plan price does not reach it
Say this plainly rather than let it be assumed. Nox-Billings is a scoped custom deployment, quoted and priced separately against your own configuration, and the platform plan price never applies to it — the same is true of NoxCRM and Nox-Tickets. Growth is ₹1,600/month or ₹15,000/year, includes a 30-day trial, 10 users, 50 active projects, and 10,000 contacts, and none of that includes expense tracking. Commerce sits on a platform plan and carries purchasing and stock there, which is a different job: there is no claim, no approver and no reimbursement in it. If what you need is a card feed, an OCR pipeline or an approval rule engine, say so in the conversation — that is a different product conversation, not a plan question.
Expense and spend questions, answered before you buy
How is this different from the expense tracking page you already have?
The general page at /expense-tracking-software-small-business is the right starting point if you want to know what expense tracking is and whether the category fits. This page answers a narrower and harder question: who decides that a particular expense is allowed, and what has to happen to the money afterwards for the record to be true. If you are still choosing a category of product, read that page first. If you already know you are recording expenses and cannot get them approved cleanly, you are in the right place.
Who approves an expense?
A person, and there is no routing in NoxOrigin to do it for you. There is no automated approval routing, no expense policy rule engine, no multi-step chain, no delegated approver, no escalation on a missed deadline and no tolerance band that approves small claims on its own. What you get is a record of the claim, the document behind it, the name of the person who accepted it, and the payment that followed. The judgement is the control, and the record is what makes the judgement arguable six months later instead of a memory.
Can it read the receipt and fill the claim in?
No. There is no receipt OCR, no invoice extraction, no photograph-to-claim flow and no confidence score on a recognised line. A claim is entered by the person who spent the money or by whoever they hand it to, from a document they are holding. We regard that as the honest arrangement: an extracted figure carries an authority it has not earned, and the person who signed for the spend is the one who can be asked what it was.
Can it import a corporate card feed or a bank statement?
No, and we hold no bank connection and read no statements. There is no corporate-card feed, no card-network import, no bank-feed import, no CSV statement parser and no auto-matching of a bank line to a claim. Money entering the business is recorded by a person, as a payment record, and allocated by a person. An invoice and a payment are different records — paid is a projection of allocations rather than a stored flag — so even a manual payment that has not been allocated has not reduced anything yet.
Is an expense claim validated against a policy?
No. There is no expense policy rule engine, no per-category limit, no receipt-required flag, no night-only flag, no out-of-policy warning and no compliance score. Your policy is a document your team reads and argues with, and what NoxOrigin records is who accepted what. This page publishes no policy compliance rate, no rejection rate, no average claim size and no spend per employee, because each of those is a ratio chosen after the result is known and none of them describes your business.
Can I see who claimed what, per person, and what it cost the project?
Yes, as records you read rather than as a score. What a person claimed, on what document, who accepted it, what was paid and what remains outstanding are all held against the same chain as the rest of the business. What you cannot do is divide that cost by the hours behind it, because NoxOrigin has no timesheet record and no payroll module. Expense cost is a figure against a project, and a margin is a comparison of two records rather than a rate per hour.
Is this included in the platform plan price?
No, and this is the boundary that surprises people most. Expense tracking is a Nox-Billings capability. Nox-Billings is a scoped custom deployment, quoted and priced separately against your own configuration, and the platform plan price never applies to it. The plan prices on this page are NoxOrigin platform plans — NoxCRM, Nox-Billings and Nox-Tickets are all scoped custom deployments. Commerce does carry purchasing and stock movement on a platform plan, but that is buying and inventory, not expense approval: there is no claim, no approver and no reimbursement anywhere in it. We would rather you hear that boundary here than discover it in a quote.
Can it stop the same receipt being claimed twice?
Not automatically. Nothing in NoxOrigin compares an incoming claim against previously paid claims and warns you that the document has been seen. Duplicate detection flags candidate pairs and a person reviews them; the same policy is a setup decision rather than a running one, and nothing merges on its own. Catching a resubmitted receipt is a person reading the record, which is a weak control — but it is an honest one, and it is the same control the rest of the expense routine depends on.
Tell us whether you need the bank to tell you what was spent.
If you do, we will say so before you spend any more of your time here, because NoxOrigin has no receipt OCR, no corporate-card feed, no bank-feed import, no expense policy rule engine and no automated approval routing, and we hold no bank connection. What it does have is the part that survives an audit: a claim with a document behind it, a named person who accepted it, and a payment recorded and allocated as a separate record. And expense tracking is Nox-Billings, which is a scoped deployment — not a platform plan, and not something a single plan price will quietly cover.