Restaurant billing software with no table management, no floor plan, no KDS and no waiter handheld — and that is the whole boundary
Restaurant software is a table-and-kitchen system first and a billing system second. NoxOrigin is the second thing and has no ambition to become the first. There is no table management, no floor plan, no kitchen display system, no waiter handheld, no order-to-kitchen flow, no online ordering or delivery-platform integration, no recipe or portion costing, and no per-guest split beyond what a document can express. What it does do is record a bill as a set of lines against a customer, total it correctly, and keep the money allocated to it. The reason the list above is long is that a billing document is not a small restaurant system; it is a different system that happens to end at the same moment the table pays.
Four things a restaurant system does, and the three things you get instead
A floor, a kitchen, a handheld, and a split-bill screen are the four. None of them are in NoxOrigin in any form. The replacement is much smaller and genuinely useful for the part of the day that happens after the last guest leaves, which is why it is worth being precise about rather than vague.
No table management and no floor plan
There is no table record, no section, no floor plan, no server or waiter assignment, no cover count, no table transfer and no waitlist. None of those exist in NoxOrigin in any form. This is a real limitation rather than an unfinished feature, and it is better to have it stated here than discovered on a busy evening: seating is a spatial problem about a room and a shift, and a billing document has no idea what a room is.
No kitchen display and no order-to-kitchen flow
There is no kitchen display system, no course firing, no prep or station routing, no order-type routing between dine-in, takeaway and delivery, and no order state a kitchen can see. Nothing is sent to a kitchen, because there is no kitchen-side object to send it to. Order-to-kitchen is the centre of a restaurant system, and pretending a document can play that role would be the dishonest half of this page.
No waiter handheld, and a split only where a document can express it
There is no handheld device, no offline order-taking on the floor, and no split of one open bill in place. A split is expressed by raising a second document against the same customer and allocating each payment separately, which is true and auditable but slower than tapping a table. A system that can re-divide a live bill is a different product with a different risk profile, and it is not this one.
What there is instead: lines against a customer, a correct total, and money allocated to it
A bill as a set of lines, each with a description, a quantity, a rate and a stated tax treatment, raised against a customer record. The total is arithmetic you can redo by hand. The payment is a separate record, and the person who received the money decides which bill it settles. Three things held as records, so that a week of service leaves a readable statement of what was owed and what arrived.
A service routine where the bill and the money stay two separate records
Six steps, and the last one is the difference between a restaurant that knows what it is owed and one that knows what it was handed. Everything before it is arithmetic you can redo by hand.
Decide what the bill is attached to, before the first line goes on
A restaurant bill can be raised against a walk-in, a named guest, a company, or a catering customer paying later, and those four cases have completely different consequences for the money. Deciding this is a person’s decision at the start, and it is the reason the record can be read afterwards. Attaching everything to a single walk-in customer is the shortcut that makes a month of service unreadable.
Enter each item as a line with a quantity, a rate and a tax treatment
A line is a description, a quantity, a rate and the tax treatment you decided applies. Keeping the tax treatment on the line rather than assumed at the top is what makes the total checkable later, because the rate is then visible on the document instead of inferred from a setting somebody changed. A bill whose total cannot be reproduced by hand is a bill nobody can defend.
Apply the discount a person approved, not one the system decided
Discounts in NoxOrigin are threshold-based and, above a threshold, approved by a person with the authority to approve it, with the override recorded. There is no automatic promotion engine, no happy-hour rule, no loyalty discount and no campaign that prices a table down on its own. Whether a discount reduces the taxable value before tax is a question for your chartered accountant, and the record is deliberately neutral about it.
Split by writing a second document, and say so in the record
If two guests pay separately, the honest expression is two documents against the same customer, each with its own lines, total and payment allocated. It is slower than a screen that re-divides one open bill, and it is also the version that survives a dispute six weeks later, because each half is a record somebody can read. Where the split was a decision, write down who decided it and why.
Raise the invoice and read the total before the day ends
The invoice is a document with a number, and the number is the sum of the lines plus the tax treatment stated on them. Reading it once at the end of service is the cheapest control there is: a line entered in the wrong column is obvious in the total and invisible for a month. NoxOrigin does not file GST returns, does not generate an e-invoice and does not submit anything to any authority.
Record the payment as its own record, and allocate it the same evening
Money received does not reduce anything until a person allocates it. Paid is a projection of allocations rather than a stored flag, which is exactly why a table that paid and a table that did not cannot be told apart by the room but can be told apart by the record. Allocating at the end of service is not paperwork for its own sake: the unallocated amount is the one figure nobody can chase on Monday.
Four lines, a discount, a split, and a total that can be checked by hand
Every figure in this section is constructed for this page so the arithmetic can be checked. It is not a NoxOrigin result, not a customer’s bill and not a benchmark. The 5% appears only so the addition can be verified; it is not a tax position. NoxOrigin does not determine place of supply, does not decide whether a rate is right, and does not file GST returns or generate an e-invoice. This page publishes no average bill, no food cost percentage, no covers per hour and no industry figure for any of them.
The four lines, at constructed menu prices
2 × 220 = 440, plus one at 180, plus one at 140, so the taxable value is 440 + 180 + 140 = 760. GST at 5% of 760 is 760 × 0.05 = 38, and the total is 760 + 38 = 798. Check it a different way: 798 ÷ 1.05 = 760 exactly, so the total and the lines agree.
The bill as a document against a customer
Those four lines, the tax treatment and the total become an invoice with a number, raised against the customer record the table belongs to. 798 is the number a person can add up, and the lines it came from are on the document rather than in a setting.
The discount, and the question it hands to your accountant
A 50 rupee discount applied to the taxable value gives 760 − 50 = 710, and GST on that is 710 × 0.05 = 35.50, so the total becomes 710 + 35.50 = 745.50. Whether a discount should instead be treated after tax, changing the total to 798 − 50 = 748, is a treatment question for your chartered accountant. The record holds the line; it does not settle the treatment.
The split, written as two documents
Two guests pay separately, so the honest expression is two documents against the same customer: one for 445.50 and one for 300, which is 745.50 across both. 445.50 + 300 = 745.50, the same total as before the split. That is the point: a split that preserves the total and leaves two readable records can be checked six weeks later, and a bill re-divided in place cannot.
The payment, recorded and allocated the same evening
One guest pays 500. Recorded as a payment, it reduces nothing until a person allocates it: 500 against the 445.50 bill leaves 445.50 − 500 = a credit of 54.50 to be applied to the second bill, giving 300 − 54.50 = 245.50 still outstanding. Until that allocation is made by a person, the 500 is simply money received, and the outstanding figure nobody can trust is the one sitting in the unallocated queue.
The figure this page will not give you
There is no average bill, no covers-per-hour figure, no table-turn time, no food cost percentage, no labour cost ratio and no industry benchmark anywhere here. Each would be a ratio against a chosen denominator — per cover, per hour, per dish — and the denominator is chosen after the result is known. A number printed on a competitor’s page would describe their service, not yours, so we print none.
What was asked for, and the honest answer
If the first five rows apply to you, stop here and buy a hospitality point-of-sale system. The rest is what NoxOrigin does with a bill somebody has written and the money that arrived against it.
| What a buyer asks for | In NoxOrigin |
|---|---|
| Manage tables, sections and a floor plan | No. There is no table record, no floor plan, no section, no server assignment, no cover count and no table transfer. A hospitality POS owns the room. |
| Fire orders to a kitchen display | No. No kitchen display, no course firing, no station routing, no order-type routing and no handheld for the floor. Nothing is sent to a kitchen from here. |
| Take orders online or through a delivery app | No. No online ordering channel, no delivery-platform integration and no aggregator settlement reconciliation against a platform statement. |
| Cost a dish by recipe and portion | No. No recipe, no yield, no ingredient explosion and no food cost percentage. A line is a description, a quantity, a rate and a tax treatment. |
| Split one live bill between two guests | Only as separate documents. Two documents against the same customer, each totalled, each with a payment allocated to it. No in-place re-division of one open bill, and no per-seat settlement. |
| Record a bill and total it correctly | Yes. Lines with quantity, rate and stated tax treatment, a total that is the arithmetic of those lines, and a number on the document. |
| Control who discounts what | Yes. Threshold-based discount approval, a named approver above the threshold, and the override recorded. There is no automatic promotion or campaign pricing. |
| Handle a catering or company account on terms | Yes, as a customer record with a quote, an invoice and an allocated payment. Credit terms are the customer’s terms, not a lending product: no dunning, no card-on-file, no auto-debit, no credit bureau. |
| Handle a change of scope on a catering engagement | 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. |
| Post the bill to the statutory books | No. NoxOrigin does not file GST returns or any other statutory return, does not generate an e-invoice, does not determine place of supply and does not hold a bank connection or any bank credential. |
Where this is the wrong tool
A restaurant reader is likely to assume a floor and a kitchen are present, because the page title sounds like they are. The list below is the set of assumptions this page exists to remove.
If you need a floor, this is the wrong product
No tables, no floor plan, no sections, no server assignment and no cover count. A hospitality POS owns the room; NoxOrigin owns the document and the money. Thirty seconds spent reading that sentence correctly is worth more to you than the rest of this page.
Nothing here sends an order to a kitchen
No kitchen display, no course firing, no station routing, no order-type routing and no handheld for the floor. The path from a guest to a cook does not exist here, and a billing document is not a substitute for it.
Nothing here integrates with a delivery or ordering platform
No online ordering channel, no aggregator integration and no settlement reconciliation against a platform statement. If your orders arrive through an app, that app is the system of record for the order and the money, and this page is downstream of it.
This is not a tax product and it does not post to your books
NoxOrigin does not file GST returns or any other statutory return, does not generate an e-invoice, does not determine place of supply, and does not decide the correct rate or input credit position. That is your chartered accountant’s call. The 5% used in the worked example below is arithmetic, present so the total can be checked by hand.
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 received-but-unallocated amount is worth chasing the same evening. There is no dunning, no card-on-file, no auto-debit and no credit bureau in any of this.
Merge is a setup decision, and nothing merges automatically
Duplicate detection flags candidate pairs and a person reviews them. Two records for one guest split the billed and collected figures exactly as thoroughly as they split the record, so the merge policy is agreed at setup rather than assumed to be running.
A menu engineering or recipe product is a separate purchase
No recipe, no portion, no yield, no ingredient explosion and no food cost percentage. A line is a description, a quantity, a rate and a tax treatment. If the dish cost is the thing you need to know, that is a menu discipline held somewhere else.
Bills, allocations and outstanding value on the plan that matches your bill volume
Growth is ₹1,600/month or ₹15,000/year, includes a 30-day trial, 10 users, 50 active projects, and 10,000 contacts. Say this plainly rather than let it be assumed: these are NoxOrigin platform plans. NoxCRM, Nox-Billings and Nox-Tickets are scoped custom deployments, quoted and priced separately against your own configuration, and the platform plan price never applies to any of them. A single till that bills stock is Commerce work and a different conversation; if what you need is a floor and a kitchen display, say so — that is a different product conversation, not a plan question.
Restaurant billing questions, answered before you buy
Is NoxOrigin a restaurant point-of-sale system?
No. This is not a point-of-sale system for hospitality and it is not one for a table, a cover, or a kitchen. There is no table management, no floor plan, no section or server assignment, no cover count, no kitchen display system, no order-to-kitchen routing, no waiter handheld and no online ordering or delivery-platform integration. In NoxOrigin a bill is a document: a set of lines raised against a customer, totalled, and then paid. If your day is about seating, covers and firing orders, buy a hospitality POS. If your day is about getting the money that is owed to you onto the right record, this page is about that.
Can it split a bill between guests or across two cards?
Only to the extent a document can express it. A split is expressed by raising separate documents against the same customer, each with its own lines and its own total, and a payment is then allocated to each of them by a person. There is no split-bill screen that re-divides one open bill in place, no per-seat allocation, and no per-guest partial settlement inside a single document. Two documents is a true split. Anything that needs the original bill rewritten in place is a different product.
Does it cost a portion or a recipe?
No. There is no recipe, no portion, no ingredient explosion, no yield, no food cost percentage and no menu engineering. A line on an invoice in NoxOrigin is a description, a quantity, a rate and a tax treatment. Stock variants, units, locations, receiving and stock deduction are Commerce records, and they are not the same thing as a recipe: knowing that you hold 40 kg of flour tells you nothing about what one plate consumes. Costing a dish properly is a menu decision and a discipline, not a field on an invoice.
What happens to the money after the table pays?
The payment is recorded as its own record and then allocated to the bill by a person. An invoice and a payment are different records, so paid is a projection of allocations rather than a stored flag. This is the part that matters after service ends: a table that paid in full and a table that paid half look identical in the room, and only the allocation tells them apart. There is no dunning, no card-on-file, no auto-debit and no credit bureau here.
Is this a tax product?
No. NoxOrigin does not file GST returns or any other statutory return, does not generate an e-invoice, does not determine place of supply, and does not decide whether a rate or an input credit position is right. It produces invoice records that the return arithmetic can be summed from, so a person can check the total by hand before anything is filed. How a restaurant rate is applied, and how a discount affects the taxable value, is a question for your chartered accountant.
Can it run a shift, a cashier and a day-end?
For a counter, yes, and the boundary is worth naming precisely. Commerce holds point-of-sale billing, staff logins, PIN access, discount thresholds, per-employee activity and day-end comparison of expected against counted cash. That is a counter that sells recorded stock. It is not a dining room: there is no table to open, no course to fire and no cover count to reconcile. The /day-end-business-reporting-software page covers the closing routine in detail.
Can it handle delivery or take-away orders from an app?
No. There is no online ordering channel, no delivery-platform integration, no aggregator settlement reconciliation and no kitchen-facing order feed. If orders arrive from a third-party app, the money arrives through that platform and the statement comes from them, and reconciling it is a job the platform's own reporting does. What NoxOrigin does with the result is record the bill and allocate the payment, which is the last step rather than the whole one.
Is this included in the platform plan price?
The plan prices on this page are NoxOrigin platform plans. NoxCRM, Nox-Billings and Nox-Tickets are scoped custom deployments, quoted and priced separately against your own configuration, and the platform plan price never applies to any of them. A single till that needs stock-linked billing is a different conversation from a dining room, so say which one you have rather than assuming a plan price covers the category.
Tell us whether you need the floor or the money.
If you need the floor, we will say so before you spend any more of your time here, because NoxOrigin has no table management, no floor plan, no kitchen display, no waiter handheld, no ordering-platform integration and no recipe costing, and no plan on this site changes that. What it does have is the part after the guest leaves: a bill as lines against a customer, a total you can add up again, and a payment recorded as its own record and allocated by a person — so that what was owed and what arrived are both still readable on Monday.