> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alforse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Invoices

> The billing documents — what you charge customers, and what suppliers charge you.

An **invoice** records an amount owed. A **sales invoice** bills a customer; a **purchase invoice** records a supplier bill. Both originate from upstream documents, post to the ledger, and are settled by a separate posted payment or credit or debit memo.

## Where they come from

A **sales invoice** is raised from a sales order, or from a **posted shipment**: billing on the order or billing on what actually shipped. A **purchase invoice** is raised from a purchase order, keeping the lines that still have something to bill. Either way the new invoice opens at **Draft**, fully editable, and links each line back to the order line it bills. A [contract](/docs/reference/contracts.md) or a [rental agreement](/docs/reference/rental-agreements.md) also drafts sales invoices as its billing falls due.

A sales invoice's **"Ship To"**, on its **Shipping** card, is one of the customer's locations. An invoice from a sales order takes the order's delivery location (the drop-ship location on a drop shipment), a contract invoice takes the contract's **"Ship To"**, and a rental invoice takes the agreement's **"Rental Site"**. The PDF prints it as the Ship To address, and [sales rules](/docs/reference/sales-rules.md) check the invoice's own lines against it. It is never the bill-to.

NOTE

A purchase invoice reconciles on the **purchase order line**, not on a receipt. There's no direct receipt link, and a receipt isn't even required to bill. Posting clears the goods-received-not-invoiced accrual against the shared order line and books any price difference to variance.

## Status lifecycle

Both invoice types start in **Draft** and become read-only after leaving it. Their lifecycles are equivalent but use different names for some states.

| | Sales invoice | Purchase invoice |
| - | - | - |
| Drafting | Draft, Pending | Draft, Pending |
| Posted | **Submitted** | **Open** |
| Paying | Partially Paid → Paid | Partially Paid → Paid |
| Reversed | Voided | Voided |
| Memo applied | Credit Note Issued | Debit Note Issued |
| Past due | Overdue | Overdue |

The posted state has a different name on each side, **Submitted** for sales and **Open** for purchase, but means the same thing: posted to the ledger, awaiting payment. **Overdue**, **Partially Paid**, and **Paid** aren't set by hand; they're computed from the invoice's settlements and due date. An unpaid invoice past its `dateDue` reads **Overdue**; once settlements cover the whole balance it reads **Paid**.

## Line types

Most invoice line types populate details from an item. Sales and purchase invoices differ in these supported types:

| Type | Sales invoice | Purchase invoice |
| - | - | - |
| Part, Service, Material, Tool, Consumable | Yes | Yes |
| Comment (a note, no charge) | Yes | Yes |
| Fixed Asset | Yes | Yes |
| Rental (drafted from a rental agreement, read-only) | Yes | — |
| G/L Account (charge straight to an account) | — | Yes |

A sales invoice line can carry a **"Discount (%)"**. It discounts the line's quantity times unit price only: add-ons and shipping are charged in full, and tax is charged on the discounted amount. The line keeps its list unit price, and the invoice and its PDF show the discount beside it.

A **G/L Account** line lets a purchase invoice book a cost directly to a ledger account with a description: freight, a fee, anything without an item behind it. Sales invoices don't offer it.

A **Fixed Asset** line exists on both sides: on a sales invoice it bills a capitalized asset, and on a purchase invoice (the line form's **"Asset"** tab) it buys an asset or adds cost to one under construction.

Alforse screenshot**Purchase invoice line form with the Item, GL Account and Asset tabs, the Asset tab selected**

A purchase invoice line picks its type by tab: an item, a ledger account, or a fixed asset.

A **Rental** line is never added by hand: [rental agreement](/docs/reference/rental-agreements.md) billing writes one per billing period or charge, with no item, and it posts to lease accounts rather than to sales.

On a unit treated as a rental, rent posts to contract assets and deferred revenue, and the revenue recognition run releases it across its period. An early-return credit is drafted as a credit memo, not an invoice line; posting it takes the credit off deferred revenue, and off rental income for any part already recognized.

On a unit treated as a sale, rent and the purchase option credit net investment in leases, and the purchase option also settles the rest of the unit's net investment: a shortfall to cost of goods sold, an excess to lease revenue. A charge posts to rental income either way.

## Posting

Posting creates general-ledger entries: receivables against sales for a sales invoice, or payables against inventory or WIP for a purchase invoice. Posting also updates invoiced quantities on order lines and records the posting date.

HEADS UP

Posting never marks an invoice **Paid** — it lands on **Submitted** or **Open**. Settling it is a separate, deliberate step. A posted invoice can't be deleted either; to undo one you **void** it, which writes reversing entries rather than erasing history.

## Settling an invoice

A posted invoice is settled by applying another posted document. An **invoice settlement** links that document to the invoice for a specified amount.

A **payment** moves cash. A **Receipt** is money in from a customer (it settles sales invoices); a **Disbursement** is money out to a supplier (it settles purchase invoices). A payment carries a bank account, a date, a currency, and a total, and moves **Draft → Posted → Voided** like the invoice itself. While it's **Draft** you stage which invoices it applies to and for how much; posting it books the cash to the ledger — bank against the receivables or payables control account — and freezes those applications.

A **credit or debit memo** settles without cash. It's a party, an amount, and a reason: a **Credit** memo lowers what a customer owes (a return or allowance) or raises what you owe a supplier; a **Debit** memo does the reverse. Its offset is a general-ledger reason account, not the bank. A memo posts **Draft → Posted → Voided** too, and posting an applied credit against a customer invoice is what flips that invoice to **Credit Note Issued** (a supplier invoice reads **Debit Note Issued**). A memo belongs to exactly one party — a customer or a supplier, never both.

NOTE

An **invoice settlement** carries three amounts, not one: **applied** (cash or credit that reduces the balance), **discount** (an early-payment discount you're granting), and **write-off** (a tiny remainder you're forgiving to the write-off account). At least one has to be positive. A memo-sourced settlement can only carry an applied amount — discounts and write-offs are for cash payments.

### What if a payment overpays?

Applying **more than an invoice's open balance** is blocked per-invoice — a settlement can't exceed what's left to collect on that invoice. But a payment's **cash total can exceed everything it applies**: the excess stays on the party's account as an unapplied credit, ready to apply to a later invoice. You can also run the reverse — a payment with **zero cash** that only applies the party's existing posted credits to open invoices. Applying more credit than the party actually has, though, errors out.

### Voiding and dust

Void reverses, it doesn't erase. Voiding a posted payment or memo writes a mirror-image journal and moves it to **Voided**. You can't void an invoice that still has payments applied — reverse (or unapply) those first. And you can't edit a payment's applications once it's posted; to change how a posted payment lands, void it and re-enter it.

GOOD TO KNOW

Alforse forgives **dust**. When settlements leave a balance under one cent — smaller than the currency can represent — the invoice is treated as fully **Paid** and its balance reads zero, rather than sitting forever a fraction of a cent short.

## Related

**Sales orders**

The order a sales invoice bills against.

[Open](/docs/reference/sales-orders.md)

**Purchase orders**

The order a purchase invoice reconciles to, line by line.

[Open](/docs/reference/purchase-orders.md)

**Accounting**

Where a posted invoice's ledger entries land.

[Open](/docs/reference/accounting.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.