The five stages of a sale
A complete sale in AccountDesq can touch up to five documents: Customer, Quote, Sales Order, Invoice, and Payment. Only two of them are required - Invoice and Payment. Everything else exists to serve a specific real-world need: a Quote when a customer needs pricing before committing, a Sales Order when delivery happens separately from (and possibly before) billing. If neither applies to how you sell, you can create a Customer and go straight to an Invoice.
The full path (every step after Customer is optional except Invoice and Payment)
- 1
1. Customer
Who you are billing - set up once, reused everywhere.
- 2
2. Quote (optional)
Pricing the customer has to agree to before you do the work.
- 3
3. Sales Order (optional)
A commitment to deliver, tracked separately from billing.
- 4
4. Invoice
The actual financial event - this is what posts to your books.
- 5
5. Payment
Cash actually arriving, allocated against what it settles.
Nothing is real until it posts
A Quote and a Sales Order are both commitments - useful records, but neither one touches your General Ledger. The first time a sale becomes an actual financial transaction is when an Invoice is issued. Keep that distinction in mind through the rest of this guide: "created" and "posted" are not the same thing.
Stage 1 — Set up the customer
A Customer record holds everything every later document reuses: billing/shipping addresses (and a full multi-address book if they have more than one location), tax treatment, payment terms, credit limit, and an optional opening balance. Only the name is actually required - everything else can be filled in later.
On the list vs. the detail screen
Customers list
- Every customer, one row each: name, email, phone, type, and status
- Search by name/display name/email, sort any column, bulk-select for actions
- A quick census of who you sell to - not where their money or history lives
One customer, opened
- Full profile - addresses, tax treatment, payment terms, credit limit
- An Activity timeline of everything that touched this customer (invoices, payments, credit notes, edits)
- The single place their running balance and receivables risk actually live
| Field | What it actually controls |
|---|---|
| Tax treatment | "registered", "unregistered", or "overseas" - feeds the Tax Engine’s determination on every invoice for this customer |
| Payment terms | One of Due on receipt, Net 15, Net 30, Net 45, Net 60 - defaults to Net 30 if left unset, and pre-fills every new invoice’s due date |
| Credit limit | A soft ceiling used by reports and readiness checks - it does not hard-block a sale |
| Opening balance | What this customer already owed you before you started using AccountDesq - see below, this is not just a display number |
Fields worth setting deliberately, not leaving on defaults
Opening balance posts a real journal entry
Set (or later change) a customer’s opening balance and AccountDesq posts an actual entry the moment you save: Dr Accounts Receivable / Cr Opening Balance Equity. It is not a cosmetic starting number - it is real double-entry bookkeeping, in the same open accounting period as everything else, subject to the same period-lock rules as an invoice or payment.
One more thing worth knowing: AccountDesq currently runs in single-base-currency mode. A customer’s currency field always resolves to your workspace’s base currency, even if you set something else - there is no per-customer multi-currency billing today.
Stage 2 — Quote (optional)
Use a Quote when a customer needs to agree to pricing before you commit to the work. A Quote never posts to the ledger - it is purely a commercial proposal that can be accepted, rejected, or left to expire.
On the list vs. the detail screen
Quotes list
- Every quote, one row each: number, title, status, valid-until date, and total
- Fast pipeline read - what’s still open, what’s about to expire
One quote, opened
- Sent/accepted/rejected timestamps, line items, and a shareable customer link (once sent)
- If it converted, a direct link to the Invoice it became
- The place to actually accept, reject, or convert - not available from the list
| Status | Meaning | Can move to |
|---|---|---|
| draft | Being prepared, not yet sent | sent, void |
| sent | Delivered to the customer, awaiting a response | viewed, accepted, rejected, expired, void |
| viewed | Customer has opened it | accepted, rejected, expired, void |
| accepted | Customer agreed - ready to convert to an invoice | converted, partially_invoiced |
| rejected / expired / void | Terminal - no further action | — |
| converted / partially_invoiced | Already turned into one or more invoices | partially_invoiced (further billing) |
Quote status - what each one means and where it can go next
Expiry is checked on read, not by a background job
A Quote with a validUntil date does become "expired" - but only the next time someone actually opens or lists it, not automatically at midnight on the validity date. There is no scheduled job scanning for expired quotes. In practice this makes no visible difference (you’ll never see a stale "sent" quote once you or the customer look at it again), but if you’re building a report or expecting a notification the moment a quote lapses, that does not exist today.
A Quote does not automatically become a Sales Order
A Sales Order can optionally reference the Quote it came from, for reporting and traceability - but there is no "Convert to Sales Order" button anywhere, and no automatic conversion. If your workflow genuinely needs Quote → Sales Order, you currently create the Sales Order separately and it will simply not be linked back to the quote unless that link is set some other way. Don’t plan a workflow around a conversion feature this product doesn’t have.
Quote → Invoice (the real, working conversion)
- 1
Customer accepts
The Quote must be in "accepted" status - AccountDesq will not convert a draft or a merely-sent quote.
- 2
Convert (all or part)
Each line tracks how much of it has already been invoiced, so you can bill a quote in more than one pass - a partial conversion leaves the quote "partially_invoiced"; billing everything remaining marks it "converted".
- 3
Tax gets a second look
If the quote couldn’t fully determine tax when it was saved, the resulting invoice re-runs real tax determination rather than copying forward a $0 that was never actually calculated.
Stage 3 — Sales Order (optional)
Use a Sales Order when delivery is tracked as its own step, separate from - and often before - billing: you commit to supplying goods or services, deliver them (possibly in more than one shipment), and only then invoice for what actually went out.
On the list vs. the detail screen
Sales Orders list
- Every sales order: number, customer, title, status, expected delivery date, and total
- A pipeline view - what’s still owed to a customer, and what’s coming due
One sales order, opened
- Delivered-vs-invoiced progress per line, since both roll up independently
- Create invoice (once something has been delivered but not yet billed) and Close short live here, not on the list
| Status | Meaning |
|---|---|
| draft | Being prepared |
| issued | Committed - ready for delivery and/or invoicing |
| partially_delivered / delivered | Set automatically as Delivery Challans are recorded against it - never set manually |
| closed | Done - terminal |
| void | Cancelled - only possible from draft/issued, before any delivery exists |
Sales Order status - what each one means
A Sales Order never touches your books - and neither does a Delivery Challan
Creating, issuing, or delivering against a Sales Order posts nothing to the General Ledger and does not decrement stock-on-hand. A Delivery Challan is a documentary record only - it updates the Sales Order’s delivered quantity and status, nothing more. The real stock movement and the real cost-of-goods-sold entry both happen at exactly one moment: when the resulting Invoice is issued. If you’re trying to reconcile inventory movement against Sales Orders, look at the Invoice instead.
Stock reservation is tied to the Invoice, not the Sales Order
If you were expecting a Sales Order to "reserve" stock the moment it’s issued, that isn’t how it works today - reservations are created and released against Invoice drafts, not Sales Orders.
Sales Order → Invoice (bills exactly what’s been delivered but not yet billed)
- 1
Deliver (one or more Delivery Challans)
Each line’s delivered quantity accumulates - you can deliver in multiple shipments against one Sales Order.
- 2
Create Invoice
One action bills exactly (delivered − already invoiced) on every line - there’s no manual quantity entry to get wrong.
- 3
Repeat as needed
Deliver more, invoice the new remainder - the Sales Order tracks both running totals per line throughout.
Deliveries: tracking what actually shipped
A Delivery Challan records what physically shipped against a Sales Order - its own document, numbered DC-{year}-{sequence}, with a delivery date, warehouse, an optional vehicle number, and one line per item shipped. There is no separate "Delivery status" field to track: a delivery is simply recorded or voided, and it is the Sales Order’s own status (draft/issued/partially_delivered/delivered/closed/void) that reflects delivery progress automatically as challans come in.
You create a delivery from the Sales Order’s own detail page, not from a standalone "new delivery" screen - "Record delivery" shows exactly what remains on each line (ordered minus already delivered) and won’t let you enter more than that. Ship in as many partial deliveries as you need; each one only accepts what’s genuinely still outstanding on that line.
On the list vs. the detail screen
Deliveries list
- Every delivery: number, customer, the sales order it belongs to, delivered date, and notes
- A shipping log - what went out and when, sortable by delivery date
One delivery, opened
- Warehouse, vehicle number, and the recorded-by detail behind that one shipment
- Void lives here - and is blocked outright once the quantity has already been invoiced
You can’t void a delivery once it’s been invoiced
Voiding a delivery reverses the quantity it contributed - but only if that quantity hasn’t already flowed into an invoice. If it has, voiding is blocked outright with a message telling you exactly how much is stuck. At that point the correct fix is a credit note through the Settlement Engine, not an un-delivery.
An Invoice never references a specific Delivery directly - the relationship only flows through the Sales Order’s running per-line totals (delivered vs. invoiced). Creating an invoice from a Sales Order is only offered once at least one line has been delivered but not yet billed.
Stage 4 — Invoice: the financial event
An Invoice is where a sale becomes real accounting. A draft invoice is still just a plan - editable, deletable, invisible to your financial statements. The moment you issue it, that changes: tax is finalized, stock (for tracked items) actually decrements, and a real journal entry posts.
On the list vs. the detail screen
Invoices list
- Every invoice you can see, one row each: number, title, status, due date, total, and balance due
- Search by number/title, filter by status, sort any column, export the current view as CSV
- Built for triage - which ones are overdue, which are close to paid off
One invoice, opened
- That invoice’s full lifecycle: issued/voided timestamps, line items, tax breakdown, applied payments
- The actions available depend on status - Void only shows while nothing has been paid yet
- PDF download and (if the invoice references a Sales Order) a link back to what it was converted from
| Status | Meaning | Can move to |
|---|---|---|
| draft | Editable, not yet financial | issued, void |
| issued | Posted to the ledger, locked from further editing | void, partially_paid, paid |
| partially_paid | Some but not all of the total collected | issued, paid |
| paid | Fully collected | issued, partially_paid |
| void | Cancelled - terminal | — |
Invoice status - and the one deliberate one-way door
Void only works before money moves
You can void a draft or a freshly-issued invoice with nothing paid against it yet. Once any payment has landed - partially_paid or paid - void is deliberately unavailable. The correct fix at that point is a correcting document (a Credit Note or a Debit Note, both covered below), not deleting or voiding the original. This preserves an honest audit trail: the mistake and its correction both stay visible.
Tax is calculated automatically by the Tax Engine for each line, based on the customer’s tax treatment and the item’s classification - but it is not a black box. You can see and override the tax code on any line, and every line remembers exactly which rule actually matched, so you can always answer "why was this taxed this way" later.
What actually posts when you click Issue
| Line | Amount | Direction |
|---|---|---|
| Accounts Receivable | Invoice total (incl. tax) | Debit |
| Revenue | Total minus tax | Credit |
| Tax Payable | Tax amount (only if > 0) | Credit |
| Cost of Goods Sold | Weighted-average cost of tracked items sold | Debit (only if any line is inventory-tracked) |
| Inventory | Same amount as COGS above | Credit (only if any line is inventory-tracked) |
The real journal entry behind "Issue Invoice" (one combined entry)
Every account here is resolved by its accounting PURPOSE (Accounts Receivable, Tax Payable, COGS, Inventory), not by a hardcoded account number - so it still finds the right account even if your chart of accounts uses different numbering. Because the inventory and revenue legs post in the same entry, voiding an issued invoice later reverses the sale and its cost together, in one action.
Next Best Action - what AccountDesq suggests, and why
Every invoice detail page tells you the single most useful next step, computed from real state - never a generic nudge.
| Suggestion | When it appears |
|---|---|
| Fix readiness | Draft, and something is blocking it from being sent (missing tax determination, no line items, etc.) |
| Issue | Draft, and everything checks out |
| Resolve dispute | Issued or partially paid, with an open dispute - this takes priority over payment nudges |
| Log a promise to pay | Issued or partially paid, overdue, no active promise on file |
| Record payment | Issued or partially paid, and a previously logged promise has been broken |
| (nothing shown) | Paid or void - there’s nothing left to do |
What triggers each suggestion
No fake "send a reminder" button
AccountDesq does not have an email/reminder system built in yet, so Next Best Action never suggests sending one - that would be a button promising something the product can’t actually do. The real equivalent today is logging a payment promise, which is honest about what’s actually being tracked.
Credit Notes, Debit Notes, and corrections
Once an invoice has money against it, you can’t void it - you correct it. AccountDesq has two different tools for this, and they work nothing alike under the hood.
Credit Note vs. Debit Note
Credit Note
- Reduces what a customer owes (or refunds/credits an overcharge)
- Always becomes spendable customer credit first - never touches an invoice’s balance directly
- A real settlement record, with its own reason code (return, overcharge, pricing error, goodwill, duplicate, other)
- Posts Dr Sales Returns & Allowances / Cr Customer Advances
Debit Note
- Increases what a customer owes - a correction that adds to the bill
- Not a separate document type at all - it IS an ordinary Invoice, flagged as correcting another invoice
- Goes through the exact same tax, GL-posting, and payment-allocation path as any invoice
- Because it needs to be collectible like normal revenue, it can’t be a lightweight settlement the way a Credit Note is
A "return" credit note does not touch your stock
If you issue a Credit Note with reason "return", it reverses revenue and tax - it does not automatically put the returned item back into stock-on-hand or adjust average cost. If the goods actually came back, that’s a separate, manual inventory step today.
On the list vs. the detail screen
Credit Notes list
- Every credit note: number, customer, date, reason, which invoice it corrects, amount, and status
- A correction log - what’s been reversed and why, at a glance
One credit note, opened
- What it was issued against, and (if it’s been applied) where that credit went
- A "View journal" button showing the exact posted entry, plus Reverse if it needs undoing
Recurring invoices
A Recurring Invoice Template (weekly, monthly, quarterly, or yearly) generates an ordinary draft invoice automatically every time it’s due - a scheduled job runs daily and creates what’s owed. It never issues that invoice for you: a human always reviews and issues it, exactly like any other draft. One detail worth knowing - line prices are captured when you save the template and are not silently re-priced each cycle, so a subscription keeps billing at the price it was set at until you edit the template.
On the list vs. the detail screen
Recurring Invoices list
- Every template: name, frequency, status, next invoice date, and how many it’s generated so far
- A subscription schedule - what’s active, paused, or cancelled
One template, opened
- Every invoice this template has ever generated, listed with links to each one
- Pause, Resume, and Cancel live here - a paused template simply stops generating new drafts, it doesn’t touch what’s already been created
Stage 5 — Payment: collecting the cash
A Payment starts as a draft (fully editable, nothing posted) and becomes real the moment you confirm it. From there, its status is mostly computed automatically from what’s actually happened to it - you rarely set it directly.
On the list vs. the detail screen
Customer Payments list
- Every payment: number, customer, method, status, and amount
- A cash-receipts log - what’s come in and how it was received
One payment, opened
- Exactly which invoices it was allocated to, and how much is still unallocated
- Reverse and the bank-reconciliation state live here - a draft payment shows plainly that nothing has posted yet
| Status | Meaning |
|---|---|
| draft | Not yet posted - the only stage you can freely edit or delete |
| confirmed | Posted to the ledger, not yet applied to any invoice |
| partially_allocated | Some, but not all, of the amount applied to invoices |
| fully_allocated | The entire amount applied |
| reconciled | Matched to a bank statement line - this LOCKS the payment (no further allocation or reversal without first unreconciling, with a reason) |
| void | Cancelled |
Payment status you’ll actually see (computed, not manually set)
How allocation actually works
- 1
One payment can settle many invoices
A single payment can be split across several open invoices for the same customer in one allocation.
- 2
One invoice can be settled by many payments
Partial payments over time all allocate against the same invoice until it’s fully paid.
- 3
Overpayment becomes wallet credit automatically
Whatever isn’t allocated becomes that customer’s spendable credit balance - it doesn’t just sit unexplained.
- 4
Oldest-first suggestion available
AccountDesq can suggest allocating a payment to the oldest-due invoices first; other prioritization strategies (highest-risk, largest-amount) aren’t built yet.
| Line | Amount | Direction |
|---|---|---|
| Cash or Bank (by payment source) | Full payment amount | Debit |
| Accounts Receivable | The amount actually allocated to invoices | Credit (only if > 0) |
| Customer Advances | The unallocated remainder | Credit (only if > 0) |
What posts when a payment is confirmed
The customer credit wallet
A customer’s credit balance is never a stored number - it’s calculated fresh, every time, from real transactions: unallocated payment amounts, plus credit notes, minus what’s already been spent or refunded. That live calculation, not a cached total, is what every "can they afford this?" check reads - specifically so two people spending the same credit at the same moment can’t both succeed.
| Type | What it does | Touches an invoice’s balance? |
|---|---|---|
| Credit Note | Banks value as spendable wallet credit | No - only indirectly, if applied |
| Credit Application | Spends existing wallet credit against one or more open invoices | Yes |
| Refund | Sends money out of the business (cash, bank transfer, or cheque) | No |
The three real customer-money events (there is no fourth)
"Reversal" is the undo button, not a fourth type
Any of the three settlement types above can be reversed - that posts a real, opposite journal entry and unwinds whatever the original did, rather than deleting or editing history. A couple of real limits: you can’t reverse a credit note if its value has already been spent (you’d need to reclaim the spend first), and you can’t reverse one that falls in an accounting period that’s already closed - that’s a known, documented limitation with no workaround yet. For the full decision guide on which of these to use in a given situation, see the related article below.
Bank reconciliation: closing the loop
Reconciliation is the final control step: matching a line on your actual bank statement to the payment (or refund) that caused it, inside the Banking module. Marking a payment reconciled doesn’t post anything new - it locks that payment, asserting "this deposit really happened, exactly as recorded." If something needs to change after that, you unreconcile it first, with a reason, rather than editing a locked record.
Reconciliation not balancing?
That’s a separate, common problem with its own troubleshooting guide - see the related article below for the eight most common causes, checked in the order that finds them fastest.
Disputes and broken promises
A Dispute records that a customer is contesting an invoice (price, tax, delivery, quality, duplicate billing, or something else) - it can only be raised on an invoice that’s actually been issued, and only one can be open at a time per invoice.
A dispute does not freeze the invoice
This is a common assumption worth correcting: an open dispute does not block payments, allocation, or anything else at the system level. What it does is take over Next Best Action as the top priority, ahead of any collections nudge, until it’s resolved - it’s a strong signal, not a hard lock.
A Promise to pay is tied to one specific invoice and a date. It only ever has two stored states - pending or kept - "broken" is worked out live: a pending promise becomes broken the moment its date passes while the invoice still has a balance. The moment an invoice is fully paid, any pending promise on it is automatically marked kept.
Receivables Intelligence: seeing collection risk before it’s a problem
Receivables Intelligence is where every invoice, payment, dispute, and promise across your whole customer book rolls up into one live view - four tabs (Overview, Action Center, Customers, Performance), recomputed fresh on every visit from real data. Nothing here is machine-learning or guessed: every score is a documented, rule-based formula over transactions you actually recorded, and where there isn’t enough history to estimate something honestly, it’s shown as unavailable rather than invented.
The customer health score - not just an aging bucket
Every customer starts at a score of 100 and loses points for real, specific behavior - so two customers with the same overdue amount can land in very different places if their history is different.
| Factor | Maximum impact |
|---|---|
| Share of invoices paid late | up to −25 |
| Average days paid late | up to −20 (at 60+ days average) |
| Open disputes | −8 each, capped at −16 |
| Broken payment promises | −10 each, capped at −20 |
| Share of outstanding balance that’s overdue | up to −20 |
| Credit limit utilization (only if a limit is set) | −5 at 80–100% used, −10 if over 100% |
What actually moves a customer’s health score
The result is a score (floored at 0) that sorts into healthy (80+), attention (50-79), or critical (below 50) - each with the specific reasons behind it, so "why is this customer critical" always has a real answer, not just a color.
The cash forecast - and when it honestly says "unknown"
Every open invoice gets an expected payment date, ranked by how much to trust it: an active payment promise beats everything (high confidence); failing that, a customer’s own historical average delay applied to the due date (medium confidence); failing that, the bare due date - but only for a customer with no payment history at all to weight it (low confidence). If none of these produce a date that’s still in the future, the invoice is deliberately left out of the forecast and counted as "at risk" instead, rather than showing a number nobody should trust.
Action Center vs. the priority queue - two different tools
These solve two different problems, and it’s worth knowing which one you actually want.
Action Center vs. Priority queue
Action Center
- Seven fixed work-queue categories: needs a commitment, promises due this week, broken promises, credit to apply, disputes to resolve, over credit limit, drafts to issue
- Categorical - "which bucket of problem is this"
- Best for working through one type of task at a time
Priority queue
- Every open invoice scored 0-100 on amount, age, customer risk, broken promises, and concentration, then ranked
- Numerical - "what matters most, right now, across everything"
- Best for "give me the single most important thing to do next"
Collections Operations Center is the same data, reshaped
The Collections Operations Center report (in Reports) is not a separate analysis - it deliberately calls the exact same Receivables Intelligence calculation underneath, so the two can never disagree about who owes what. It reshapes the same priority queue into one row per customer instead of per invoice, and adds a payment-method breakdown Receivables doesn’t show. Use Receivables Intelligence for the full analytical picture; use Collections Operations Center when you’re working a call list.
Seeing the rest of the pipeline: more reports
| Report | What it actually shows |
|---|---|
| Sales Intelligence Register | Every invoice with payment progress, collection risk, and health score, plus its next best action |
| Customer Financial Profile | One customer’s complete lifetime numbers, behavior pattern, and recommended next step |
| Customer Profitability Report | Customers ranked by revenue, margin, payment speed, and risk |
Where else to watch the Sales flow, beyond Receivables Intelligence
The complete flow, start to finish
One sale, every stage it can touch
- 1
Customer
Set up once - tax treatment, payment terms, credit limit. An opening balance posts a real entry immediately.
- 2
Quote (optional)
Price it, send it, get it accepted. Nothing posts yet.
- 3
Sales Order (optional)
Commit to delivery, track it in one or more Delivery Challans. Still nothing posts.
- 4
Invoice
Issue it - tax finalizes, stock decrements for tracked items, and the first real journal entry posts: Dr AR / Cr Revenue (+ Tax, + COGS/Inventory where relevant).
- 5
Payment
Confirm and allocate - Dr Cash/Bank, Cr AR for what’s applied, Cr Customer Advances for any overpayment.
- 6
Reconciliation
Match the payment to the real bank statement line - this locks it as confirmed-true.
- 7
Reports
Everything above rolls up into the Sales Register, Customer Profile, Collections Center, and AR Aging in real time.
Can I skip Quotes and Sales Orders entirely?
Yes. Both are optional. If you don’t negotiate pricing beforehand and don’t track delivery separately from billing, go straight from Customer to Invoice.
Does creating a Sales Order reserve stock?
No. Stock reservation is tied to Invoice drafts, not Sales Orders. A Sales Order is a delivery commitment with no inventory or ledger effect of its own.
Why didn’t my Quote turn into a Sales Order automatically?
It never does - that conversion doesn’t exist as a feature today. A Sales Order can reference the Quote it came from for reporting, but you create it as its own document. The real automatic conversions are Quote → Invoice and Sales Order → Invoice.
What’s actually different between a Debit Note and just editing the invoice?
You can’t edit an issued invoice - it’s locked the moment it posts. A Debit Note is a new, separate Invoice that references the one it’s correcting, carrying its own tax calculation and its own GL posting, while leaving the original invoice’s history untouched.
If a customer disputes an invoice, can they still pay it?
Yes - a dispute doesn’t block payment, allocation, or any other action. It’s a status flag that pushes "resolve this" to the top of what AccountDesq suggests you do next, nothing more.
Resources
Was this guide helpful?