Receivables & payables

Accounts receivable (AR) and accounts payable (AP) are mirror images of the same machinery: the AR helpers work over invoices, the AP helpers over bills, and both settle balances the same way. Issuing a document posts a balanced journal to the general ledger; settling it moves the sub-ledger balance.

Core objects

Receivables (AR)

• Estimates and sales orders — the front half of the sales cycle. Neither posts to the ledger; they carry the quote and the order before it becomes an invoice.
• Invoices — multi-line documents with per-line quantity, unit price, discount and tax. Issuing one (DRAFT → SENT) is what posts it.
• Customer payments — recorded against one or more invoices.
• Credit notes — reduce a receivable (and its revenue and tax) as the exact inverse of the invoice journal.
• Retainer invoices — customer advances, held as a liability until drawn down.
• Credit refunds — cash refunds paid back against a credit note.

Payables (AP)

• Purchase orders — see expenses & purchase orders.
• Bills — vendor invoices. A bill is entered as DRAFT and posts when it is opened (DRAFT → OPEN).
• Vendor payments — recorded against one or more bills.
• Vendor credits — reduce a payable (and its expense and input tax).

What you can do

• Build invoices and bills with line-level discounts and tax, derived from each line’s tax code. On the sales side, unit prices can come from the customer’s price list or the item’s own rate.
• Record full or partial payments using a shared method vocabulary (cash, cheque, card, bank transfer, ACH, UPI, wire and common online gateways); the document status advances automatically as it is settled.
• Apply credit notes and vendor credits to open documents. Applying a credit is a pure sub-ledger reallocation within AR/AP — it moves no money on the ledger, so unapplying needs no counter-entry.
• Issue cash refunds against an unapplied credit balance.
• Take customer advances through retainer invoices and draw them down later.
• Void a payment to reverse its journal (and unwind any bank-book mirror) in one transaction. A void — or un-applying a credit — that leaves a past-due document still owing keeps it OVERDUE rather than resetting it to SENT/OPEN, so the overdue signal is never hidden.

Document statuses

Invoice and bill status is a transition graph, not a straight line. Two rules shape it: PARTIALLY_PAID, PAID and OVERDUE are settlement-driven — they are set by payments and credit applications (and, for invoices, by the dunning run, which doubles as the overdue sweep), never by hand — and a document can be moved to CANCELLED or VOID only while it carries no applied payment.

Invoices

From	Can be moved to
DRAFT	SENT, CANCELLED, VOID
SENT	VIEWED, CANCELLED, VOID
VIEWED	CANCELLED, VOID
OVERDUE	CANCELLED, VOID
PARTIALLY_PAID, PAID	nothing — settle or void the payments first
CANCELLED, VOID	terminal

Bills

From	Can be moved to
DRAFT	OPEN, CANCELLED, VOID
OPEN	CANCELLED, VOID
OVERDUE	CANCELLED, VOID
PARTIALLY_PAID, PAID	nothing — settle or void the payments first
CANCELLED, VOID	terminal

Cancelling or voiding a document that has already posted reverses it in the books: the journal is reversed (dated today, so a closed period cannot strand the reversal), any stock it moved is reversed with it in the same transaction, and any time entries billed on the invoice are released back to billable. If the stock cannot be reversed — the goods have since been sold — the void is refused rather than half-applied.

Pricing

A sales line can always be priced by hand. When a line names an item and carries no rate, Accounts resolves one, in this order:

1. An explicit rate. A rate typed on the line is a human decision about money, and nothing overrides it — not even the customer’s own price list.
2. The customer’s price list, when they have an active one. A FIXED list prices the items it names; a PERCENTAGE list adjusts the item’s own rate by that percentage (negative for a discount, positive for a markup).
3. The item’s own rate. A price list is a set of overrides, not a whitelist — an item the list does not mention is sold at its own price, never at zero and never refused.

Steps 2 and 3 are API-level behaviour today: the web and mobile line editors both require a unit price, and prefill the item’s own rate as soon as you pick an item, so price-list resolution runs only for a client that leaves the rate off entirely.

Pricing runs when an invoice, estimate or sales order is created. Editing the lines of an existing document recomputes tax and totals but does not re-price them, and a conversion does not re-price either: the quote’s agreed net price (quantity, unit price, discount) is carried across verbatim into the sales order and the invoice, so you bill exactly what was quoted even if the price list has since changed. Only tax is re-derived, against the new document’s date.

A price list carries a currency because its numbers are that currency. If the list’s currency differs from the document’s, the document is refused rather than converted at a rate nobody chose — match the document’s currency, or price those lines by hand.

Note

Price lists are authored under Settings → Price Lists (fixed per-item prices, or a single percentage off list). Linking one to a customer is done through the API today — there is no picker on the contact record yet. The same resolver is also exposed as a standalone GET /price-lists/resolve lookup, so an integration can ask what an item costs a customer and get exactly the number an invoice would carry.

Delivery

A document is not only a ledger row; it is the thing the other party receives. Six documents render as a branded PDF that can be emailed with the PDF attached: the invoice, credit note, purchase order, customer payment receipt, vendor payment voucher and customer statement of account. Estimates, sales orders, bills, vendor credits and retainer invoices have no PDF today.

In the web app you can download the invoice, credit note and purchase order from the document itself, and the statement from the contacts list; the payment receipt and voucher are available through the API only. Sending is API-driven throughout — the web app has no send button yet. Customers with portal access can pull their own invoices and statement themselves.

Every PDF is rendered on the server from a fresh read of the database, never from what a browser had on screen, so the document a customer receives and the ledger behind it cannot disagree. An email goes to the contact’s own address by default and is refused outright when there is none; recipients, CC, subject and body can each be overridden per send (the statement send takes recipients and a message only). Every send is written to the audit log as the single record of “was this sent”, and the response names the transport that handled it — a deployment with no mail transport configured records the send and delivers nothing.

What a document looks like

All five templates — invoice, purchase order, credit note, payment receipt/voucher and statement — are built from one shared design system, so two different documents from you look like they came from the same company. Each opens with a header band carrying your logo, legal name, address, contact details and tax registrations (GSTIN, PAN, CIN) alongside the document title, number and dates on the right, then two panels side by side for the other party and the document’s own details, then the line table — zebra-striped, header repeated on every page, rows never split across a break, amounts right-aligned — and an emphasised bar for the figure that matters: the total, the payment, or the closing balance. Continuation pages carry a slim running header, and every page is footed with your legal name, GSTIN and CIN, a confidentiality line, the document number and Page X of Y with the generation date. Everything but the statement also carries a colour-coded status badge.

Beyond that, each document carries what it legitimately should: HSN/SAC codes, a ship-to address, bank and payment instructions, a declaration and an authorisation block on the invoice; applied, refunded and balance figures on a credit note; the invoices or bills the money was applied to on a payment receipt or voucher; dated movements with a running balance on a statement.

Amounts are formatted in exactly one place, so no two figures can be grouped or rounded differently, and amount-in-words uses Indian lakh/crore grouping. Currency is printed as a code rather than a symbol — INR 1,234.00, because the built-in PDF fonts carry no ₹ glyph. Statement figures are labelled INR and are not currency-converted.

Your logo is fetched and checked before it is embedded, and anything unreadable falls back to your legal name as text rather than failing the download.

Recurring invoices

A recurring invoice is a template, not an invoice. It carries the customer, the lines, a payment term, a currency and a schedule — daily, weekly, monthly, quarterly, half-yearly or yearly, every N of those — with a start date and an optional end date. A template is ACTIVE, STOPPED or EXPIRED: stopping and resuming is a status change, it expires when its next occurrence would fall past its end date, and an expired template can be reactivated once that date is extended.

Running the schedule turns every occurrence that has come due into a real DRAFT invoice with ordinary invoice numbering, stamped with the template it came from. Nothing posts on generation: a generated invoice is a draft like any other and enters the books only when it is sent.

What the run guarantees:

• Occurrences are anchored to the start date, not stepped from the last one, so a schedule starting on the 31st runs 31 Jan, 28 Feb, 31 Mar rather than drifting to the 28th forever. A day that does not exist in the target month clamps to that month’s last day.
• Tax and exchange rate are resolved on the generation date, never copied. A tax code means “the rate in force”, so a line naming one is re-derived; a line with no tax code keeps its stored amount, which is how a fixed hand-entered tax is expressed. A foreign-currency template with no rate on file fails that template — the run reports it and carries on — rather than booking a silent parity rate.
• Runs are idempotent and isolated. The schedule pointer advances in the same transaction as the invoice it generated, so a second run for the same date finds nothing due; each template runs in its own transaction, so a broken one rolls back only its own generations and is listed in the run’s failures. One run generates at most twelve occurrences per template.

Recurring transactions apply the same machinery to bills, expenses and journal entries. The template stores a payload and replays it through the same validation and creation path a hand-entered document uses — what comes out is indistinguishable from one — with the date rewritten to the occurrence date and any hard-coded number stripped so every generation auto-numbers. Templates are validated when they run rather than when they are saved, so a bad one fails its own recurrence, keeps failing until it is fixed, and never stops the run.

Both live on the Recurring screen, one tab each, with a Run now action. There is no built-in scheduler: a run happens when someone asks for it in the app, or when an external scheduler calls it on a timetable.

Dunning and collections

Dunning is the collections sweep over overdue receivables. It is invoice-only: there is no equivalent for bills, which reach OVERDUE only when a payment or credit is applied or reversed against them after their due date. AP aging buckets by due date regardless, so a past-due bill still ages correctly.

Policies

A dunning policy is an escalation ladder of up to nine levels. Each level states the days past due it applies from, and optionally a late fee and the revenue account that fee should land on. Levels must be consecutive from one and their grace days must strictly increase. One policy per company can be the default, and making a new one default clears the old. Fee accounts are validated when the policy is saved — anything that is not a live revenue account is refused there, rather than discovered mid-run.

The run

A run — started from the Dunning screen or by a scheduler — does two things, in order:

1. The overdue sweep. Every SENT, VIEWED or PARTIALLY_PAID invoice past its due date flips to OVERDUE. This is the only sweep that sets that status.
2. The escalation. Overdue invoices that still owe money and are not on collections hold climb at most one level per run, and only once days past due has reached that level’s grace days. Levels only ever increase, so re-running the same date changes nothing.

Each invoice that climbs gets a run item recording its old and new level and the level’s fee, its own dunning level and last-dunned timestamp updated, an in-app notification to whoever created it, and a payment-reminder email to the customer when the contact has an email address. Both messages are sent fail-open — a bounce never rolls back levels that are already committed — and the run item records whether the notification went out. Run history is kept (RUNNING, then COMPLETED or FAILED with its error), and opening a run lists the invoices it levelled.

Late fees

When a level carries both a fee amount and a revenue fee account, the run raises a separate DRAFT invoice for that fee against the same customer, in the same transaction as the escalation, with ordinary numbering and the overdue invoice’s own exchange rate. The overdue invoice’s totals are never touched, and the fee reaches the ledger only when that fee invoice is sent — exactly like any other invoice. A level with a fee amount but no fee account records the fee on the run and raises nothing.

Collections hold

An invoice that is still payable can be put on hold from its own screen (Block collections / Resume collections). While it is held, runs skip it entirely; releasing it re-enters it at the level it already had.

How it posts

• Invoices, bills, payments and credits post through the single ledger seam: issuing an invoice debits receivables and credits revenue and tax; a bill does the inverse for payables. Credits reverse the matching legs.
• Customer payments, vendor payments and expenses settle cash straight against the bank’s GL account and are bridged into the bank book so they can be matched during reconciliation.
• Estimates and sales orders never touch the ledger.

Connects to

• General ledger — every issued document and settlement lands here as a balanced journal.
• Banking — payments and refunds mirror into the bank book for matching and reconciliation.
• Reports — AR/AP aging, sales by customer/item, and the receivables/payables dashboard KPIs read from these documents.