The big picture
Where the deal becomes goods, a bill, and cash.
CRM wins the deal; Sales & Invoicing fulfils it. A confirmed sales order is the anchor. From it you raise invoices (the only step that actually moves stock and posts to the books), dispatch the goods on deliveries, collect payments, and issue credit notes for returns. Every document links back to the one before it.
The order-to-cash loop — bill first, then dispatch
Carriers, LR numbers, packages and weight, tracking links and the delivered / returned lifecycle now live on the delivery note. See Dispatch & Shipment — and remember the invoice, not the challan, is what moves stock.
The invoice is the single point where finished-goods stock leaves and the ledger posts. A delivery note records what shipped but moves no stock; a sales order tracks fulfilment but touches neither. Keep that in mind and the whole module makes sense.
Where the screens live
Invoices
Tax invoices, proforma, payments, PDFs — the module's home screen.
/sales/invoicesSales Orders
Confirmed customer orders with a fulfilment-driven next-step engine.
/sales/ordersDeliveries
Dispatch notes against a sales order — documentary, no stock move.
/sales/deliveriesE-Way Bills
Movement permits filed with the government against an invoice, credit note or challan.
/sales/eway-billsCredit Notes
Returns, short supply, or post-sale discount — with held-credit balances.
/sales/credit-notesCustomers
The customer list & 360 view (shared with CRM). GST profile lives here.
/sales/customersQuotes
Sits in the Sales branch but is a CRM surface — see the CRM guide.
/sales/quotesWho can do what
| Action | Permission |
|---|---|
| See the module | canViewSales |
| Create / finalise / cancel invoices | canCreateInvoice · canFinaliseInvoice · canCancelInvoice |
| Record a customer payment | canRecordPayment |
| Issue a credit note | canIssueCreditNote |
| Create / confirm / close sales orders | canManageSalesOrders |
| Approve a submitted sales order new | canApproveSalesOrder |
Sales & Invoicing ships in every plan — Lite, Growth and Business all include invoices, orders, deliveries and credit notes. The Quotes surface, though it lives under Sales, is a CRM feature and needs the Growth+ CRM entitlement.
Sales Orders
The order that anchors fulfilment — and a smart button that always knows the next step.
A sales order (SO/FY/NNN) is a confirmed commitment to a customer. It carries the lines, a currency, and — crucially — two independent fulfilment axes: how much has been invoiced and how much has been delivered. They move separately.
What the order carries
- Customer PO number and PO date — their paperwork reference, printed on the order.
- Delivery method — By Road / Rail / Air / Sea / Courier / Customer pickup / Hand delivery. Need another? Add it from the form and it joins the list for everyone.
- Payment terms — one shared list across sales orders, purchase orders and vendor bills (
Advance,Cash on Delivery,Due on Receipt,Net 7 … Net 60, plus staged terms such as "50% Advance & 50% Prior to Delivery"). A term with a credit period derives the due date and the status chip for you; staged terms name milestones instead, so they carry no derived due date. - Credit limit — set per customer. The check runs when the order is confirmed, against unpaid invoices plus open orders, and either warns then allows (the default) or blocks confirmation — your choice under Settings → Credit control.
Status lifecycle
Pending approval and Approved only exist for a business that switches on Settings → Sales order approval. Leave it off — the default — and an order still goes draft → confirmed in one tap, exactly as before. With it on, submitting parks the order for someone holding canApproveSalesOrder.
Approving and confirming stay separate acts. Approval says the order may go ahead; confirming is what freezes the lines and lets invoices, deliveries and work orders be raised — so an approver can say yes without also committing the numbering and the fulfilment counters.
Rejecting sends the order back rather than ending it: it becomes editable again, carries the reason it was returned, and can be re-submitted. A submission nobody has acted on can be withdrawn, and an approved order reopened for a correction lands back in draft — because an order that changed after approval has not been approved.
From confirmed onward the status is invoice-driven: it advances to partially invoiced / invoiced only as invoices are finalised against it. Delivery is a separate, derived axis (not delivered → partially → delivered) rolled up from dispatches.
Cancelled records a real order the customer called off; void nullifies one that should never have been raised — the number is kept so the series never gaps, but the document counts for nothing. Neither is reachable once anything has been invoiced or dispatched against the order, or while a work order is still building for it; short-close such an order with closed instead. Closed is now reachable straight from confirmed too, so an order that was delivered and settled outside the invoice run stops asking to be billed.
The next-step engine
The SO detail screen shows a single smart CTA that reads the order's state and fulfilment and tells you exactly what to do next:
What the SO tells you to do
* "Create work order" only appears when the line is a manufactured item and Manufacturing is on — see the Production Control guide. If the saved production plan finishes after the date on this order, the order names the machine and the day that machine runs past its shift. The banner asks for the invoice before the delivery — the goods travel against the bill. With approval on, a draft's button is Send for approval instead of Confirm order; if anything is still unbilled after dispatch, it comes back to Create invoice.
Once an order is confirmed, its lines are frozen, but per-line counters — invoicedByLine, deliveredByLine, producedByLine — keep updating on the order itself. That's how a partially-invoiced order stays consistent while the line list never changes.
Deliveries
Dispatch notes that record what shipped — and deliberately touch no stock.
A delivery order (DN/FY/NNN — "delivery note") records goods sent to a customer against a sales order. Creating one prefills each line to its remaining-to-deliver quantity. Dispatching it rolls those quantities onto the order's delivered counter; Delivered is a final status once the customer confirms receipt.
This is deliberate and important: a delivery note is a document. Dispatching it updates the order's delivered counter but writes no stock ledger entry — the invoice is the single point where finished-goods stock actually leaves. So the order of the two can never double-count stock — though the next-step banner asks for the invoice first, and that is the recommended order.
If a pre-dispatch quality control point applies to what you are shipping, the delivery form says so and will not let you dispatch while that inspection is open. Clear it in Quality first — the whole point of a pre-dispatch gate is that it is raised before the goods go, not after.
Don't confuse a customer Delivery Note (DN) here with a job-work Delivery Challan (DC) under Purchases — the DC sends material out to a vendor for subcontract and does move stock (into a per-vendor balance) and carries the manual e-way field. Different document, different side of the business.
Invoices
The document that bills the customer, relieves stock, and posts to the books — all at finalise.
An invoice starts as a draft and does nothing until you finalise it. You can raise one from a sales order (prefilled to remaining qty), from an accepted CRM quote, or from scratch for a walk-in.
Types & the document lifecycle
Four invoice types: taxInvoice (the GST bill), billOfSupply (the GST document for supplies that carry no tax), proforma (a quote-like pre-bill, no stock/GL), and a deliveryChallan invoice-type (gets a DC number, no COGS/stock). The document walks a lifecycle, with an optional approval step you can switch on in settings:
"Sent" and "Overdue" aren't statuses — they're derived (sent = it's been shared; overdue = finalised + unpaid + past due date). Payment is a separate axis: unpaid · partial · paid. When the approval step is on, the approver cannot be the person who submitted the invoice — a separation of duties enforced on the server, not merely hidden in the UI.
With Settings → GST → Composition scheme on, a new invoice — and an invoice raised from a quote, sales order or delivery — is a Bill of Supply. It charges no GST on top of the rate, takes the next number from Bill of Supply # (not the invoice series), and the PDF prints the composition declaration with no GST columns and no CGST/SGST. A tax-invoice draft already sitting there has Convert to Bill of Supply; finalising it as a tax invoice is refused until you convert it or turn the scheme off. Turning the scheme off does not rewrite documents already issued. While it is on, sales orders and quotes show the ex-tax total. An exempt customer's invoice is a different document: it stays a tax invoice, with no GST, and says the customer is tax-exempt. A Bill of Supply is filed in GSTR-1 as exempted supply, not as a B2B tax invoice.
What finalising actually does
Finalising runs one transaction that:
- Assigns the document number (INV/FY/NNN, or BOS/FY/NNN for a Bill of Supply).
- Deducts stock for each stocked line — ledger reason
invoice(−) — and blocks if there's not enough (unless overselling is allowed). - Rolls the quantities onto the source sales order's invoiced counter, advancing its status.
- Records COGS at moving-average cost and posts the journals (§09).
Cancelling a finalised invoice reverses all of it — restock (invoice_cancel +), un-rolls the SO, and reverses the journals. It is refused while the invoice still carries a payment or a credit note: reverse those first.
GST on an invoice
How Deetzo decides CGST + SGST vs IGST — and when tax is zero.
Each line is taxed on its taxable value (qty × rate, less any discount) at the line's GST rate. The only question is which tax heads the GST splits into — and that's decided by the customer's tax profile and where they are:
Which tax applies
= exempt?→ no GST
- Intra-state (customer's state = your business state) → GST splits into CGST + SGST (half each; odd paise lands in SGST).
- Inter-state (different state) → the whole GST becomes IGST.
- Zero-rated treatments (overseas / SEZ / SEZ-developer / deemed-export) always route to IGST — for LUT/bond exports you set the line rate to 0.
- Exempt customers (tax preference = exempt) are billed with no GST. That invoice is still a tax invoice. A composition dealer issues a Bill of Supply instead (§03).
- Round-off to the nearest rupee is a setting (Settings → Invoice → "Round invoice totals to the nearest rupee"). When it is on, the rounding is recorded as a separate line and you can override it.
A USD invoice runs the same GST math in document currency (there's no automatic zeroing) — exports go tax-free via the zero-rated treatment with a 0% line rate. The books always record the INR equivalent at the invoice's exchange rate. Place of supply for the split is read from the customer's state on the invoice snapshot.
Reverse charge is a switch on the customer and on the invoice (Accounting guide). HSN/SAC does not change the tax math — the line's stored rate is what is used — but a tax invoice, including a sale to a consumer, cannot be finalised while a line and its item both lack an HSN or SAC. A Bill of Supply is not blocked for a missing code. A goods line also needs a GST unit (UQC).
E-way bills
The government's permit for goods in transit — now filed from inside Deetzo.
Raise an e-way bill against a finalised invoice, a credit note or a delivery challan, and Deetzo files it with the NIC portal through the Fyn gateway, then stores the returned e-way bill number and valid-upto on the record. The register at /sales/eway-bills shows everything you have filed — generated, cancelled, and the ones the portal rejected.
Connect once, then file
Filing needs your NIC portal login, because every business files under its own GSTIN with its own API user. Open E-Way Bills → Settings and connect: Deetzo verifies the credentials against the gateway before storing them, so a login that cannot file is never saved. The password is server-side only — no client can read it back, the owner's included — and the connection status the app displays is written by the server, so nothing can fake a connection.
What you choose when you raise one
- Source document —
invoice·creditNote·deliveryChallan. - Supply type —
supply·export·skdCkd. - Transaction type —
regular·billToShipTo·billFromDispatchFrom·combination. This is what decides which extra address blocks the form asks you for. - Part B — the vehicle the goods actually travel on. File Part A now and add or update Part B later from the row menu, which is what you want when the transporter is booked after the invoice is raised.
NIC allows an e-way bill to be cancelled within 24 hours of generation, and only while it has not been verified in transit. Deetzo asks for the mandatory remark and passes the cancellation on — after that window the bill stands and you deal with it on the portal.
The e-way bill is filed for you. The IRN / e-invoice is still not generated — no signed QR, no Ack No. See §10.
Getting paid
Recording receipts, and how outstanding & ageing follow.
Record a payment against a finalised invoice from its detail screen. Each receipt is immutable and raises the invoice's amount paid; the payment status then derives itself — unpaid → partial → paid — and the customer's outstanding and ageing update.
- Modes:
cash · upi · bankTransfer · cheque · card · other. - Outstanding = grand total − payments − credit notes. Overpaying a single invoice is rejected.
- Overdue feeds the customer's aging buckets (Current / 1–30 / 31–60 / 60+) shown on the Customer 360.
- Foreign-currency receipts capture the rate and book any realised FX gain/loss vs the invoice rate.
Customer receipts allocate to a single invoice at a time — there's no multi-invoice receipt or on-account advance for customers. A genuine customer advance is modelled instead as a held credit note (§07) that you later apply. (The "Payments Made" screen with multi-bill allocation is the vendor side, under Purchases — don't confuse the two.)
Credit notes
The reverse of an invoice — for returns, short supply, or a post-sale discount.
A credit note (CN/FY/NNN) is raised against a finalised tax invoice or Bill of Supply. Against a tax invoice it reverses GST on the same split the invoice used. Against a Bill of Supply it credits the taxable amount only: the PDF uses the bill's columns (no GST % and no GST amount) and the note's line and subtotal show that taxable value, even when the line still stores the item's GST-inclusive total. Choose Goods return to put returnable stock back (ledger reason credit_note +), or Value adjustment for a price difference — custom lines, no stock movement, and a valid HSN/SAC before it can be issued.
- Capped two ways: you can't credit more of an item than was invoiced, and total credits can't exceed the invoice's grand total.
- Classic credit reduces the origin invoice's outstanding directly; a held credit note keeps an open balance you can apply to another invoice for the same customer later (this is how customer advances work).
- Cancelling a credit note (only if none of it has been consumed) reverses the restock (
credit_note_cancel−) and the GST. - Finalised credit notes flow into the customer statement and reduce outstanding.
Document templates & custom fields
Make the printed document look like your company's — and carry the fields your business actually needs.
Every printed document can be redesigned without a developer. Settings → General Settings → Document templates lists the six documents you can style, and opens an editor with a section rail on one side and a live PDF preview on the other, built from sample data so you see the change as you make it.
| Document | Printed from |
|---|---|
| Invoice | Invoice detail → Preview / Print PDF |
| Sales Order | Sales order detail |
| Purchase Order | Purchasing — see the Purchasing guide |
| Vendor Bill | Purchasing → Bills |
| Payment Made | Purchasing → Payments |
| Expense | Purchasing → Expenses (the expense voucher) |
What you can change
- Start from a preset — Classic · Modern · Compact · Spreadsheet — then adjust anything.
- Page — paper size, orientation, margins, font, colours, watermark.
- Header & footer — logo, the organisation lines, header style, footer, notes, terms, bank details, signature block.
- The line table — which columns appear and how wide they are, whether tax heads are banded, which totals rows show, and amount in words.
- Restore built-in puts everything back.
A tenant that never opens the editor keeps today's design exactly. Each document's fixed renderer only hands over to the template engine when a saved template exists for that document — so this is opt-in, per document.
Custom fields
The same editor — or Settings → Custom Fields — defines extra fields per document: Invoice · Sales Order · Purchase Order · Vendor Bill · Payment Made · Expense, alongside the CRM entities (Lead, Task, Issue, Project). A field you define is captured on the form, saved on the document, and printed under your own label in the place you give it in the template. That is how a vehicle number, a batch reference or a site name gets onto the paperwork without a code change.
The template decides how a document looks. Document prefixes & numbering (Settings → Invoice) decide what it is called — invoice, sales order, delivery challan and Bill of Supply each run their own consecutive series.
The books (GL)
What posts to the ledger, automatically, at each step.
When accounting is set up (a chart of accounts seeded), finalising an invoice, recording a receipt, and issuing a credit note each post a journal automatically:
Invoice finalised
Payment received
Credit note finalised
Invoice cancelled
These are Phase-1 postings and only run once a chart of accounts is configured; proforma and delivery-challan invoice-types post no COGS/GL. See the (upcoming) Accounting & Books guide for the ledger itself.
Not yet in the module
Being straight about the edges, so you don't go looking for what isn't there.
Deetzo does not generate an IRN / e-invoice — there is no signed QR or Ack No on the document. The invoice PDF is a standard GST tax invoice. If you are above the e-invoicing threshold, generate the IRN on the government portal for now.
An earlier edition of this guide said Deetzo could not produce a sales e-way bill. It can, since Aug 2026 — raised against an invoice, credit note or challan and filed with NIC through the Fyn gateway, with Part-B updates and 24-hour cancellation. See §05.
- Customer advances aren't a first-class "on-account" balance — use a held credit note (§07).
- Multi-invoice receipts exist for vendors, not customers (§06).
- GL postings are Phase-1 and require the chart of accounts to be set up.
Scenarios — end-to-end playbooks
The common routes through the module.
Order → invoice → deliver → collect happy path
Direct invoice (walk-in) no order
Partial invoicing staggered billing
Sale return credit note
Export invoice zero-rated
Quick reference
The tables to keep open while you learn.
Routes
| Screen | Route |
|---|---|
| Invoices (home) | /sales/invoices |
| Sales Orders | /sales/orders |
| Deliveries | /sales/deliveries |
| E-Way Bills | /sales/eway-bills |
| Credit Notes | /sales/credit-notes |
| Customers | /sales/customers |
| Quotes (CRM) | /sales/quotes |
Key states & codes
| Concept | Values |
|---|---|
| Sales-order status | draft · pendingApproval* · approved* · rejected* · confirmed · partiallyInvoiced · invoiced · closed · cancelled · voided (* only when SO approval is on) |
| Delivery status (derived) | notDelivered · partiallyDelivered · delivered |
| Delivery-order status | draft · dispatched · delivered · returned · cancelled |
| Invoice type | taxInvoice · billOfSupply · proforma · deliveryChallan |
| Invoice document status | draft · submitted_for_review · approved · finalised · cancelled |
| Invoice payment status | unpaid · partial · paid |
| Payment modes | cash · upi · bankTransfer · cheque · card · other |
| Credit-note status | draft · finalised · cancelled |
| E-way bill status | draft · generated · cancelled · failed |
| E-way source doc / supply type | invoice · creditNote · deliveryChallan · supply · export · skdCkd |
| Payment terms | Advance · Cash on Delivery · Due on Receipt · Net 7/15/30/45/60 + staged milestone terms |
| Templated documents | invoice · salesOrder · purchaseOrder · vendorBill · payment · expense — presets classic · modern · compact · spreadsheet |
| Stock reasons (sales) | invoice (−) · invoice_cancel (+) · credit_note (+) · credit_note_cancel (−) |
The invoice is the pivot. Orders track the promise, deliveries record the shipment, but only the invoice moves stock and posts money. Everything before it is documentary; everything after — payments, credit notes — adjusts what the invoice created.