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

# Receivables and revenue

> What an AR invoice posts, where output VAT lands, how a receipt clears it, and the factoring distinction the Close list polices.

# Receivables and revenue

Receivables mirror payables, one control account to the other side.
Every rule that holds for AP holds here: the entry, the sub-ledger obligation and the tax register line are one fact, written in one transaction.

## An AR invoice

Revenue is credited at the **net**, output VAT is a separate credit, and the AR control account is debited at the **total**.

| Leg                                     | Account                                 | VAS         | Dr | Cr |
| --------------------------------------- | --------------------------------------- | ----------- | -- | -- |
| the AR control leg, at the total        | `1100` trade receivables (control)      | 131         | ✓  |    |
| revenue, at the net                     | `4000` manufacturing or `4010` services | 5112 / 5113 |    | ✓  |
| output VAT, when the invoice charges it | `2100` output VAT payable               | 33311       |    | ✓  |

Written alongside it: the AR obligation in `obligations` (`kind: "invoice"`, `party_kind: "customer"`, keyed by `client_code` and the invoice's own number), and - when VAT was charged - the `direction: "output"` register line in `tax_entries` against GL `2100`.

The obligation's `amount_base` is read back off the **posted** AR leg, not computed from a rate the caller may not have supplied.
That is what lets `close_checks.ar_control_tie` compare base against base.

<Note>
  Output VAT is the twin of [input VAT](/greatbook/gl/rules-payables), and the same pair of Close checksums reads it back: the register against the GL balance, and each line's `tax_amount == ROUND(base_amount × rate)`.
  The output-VAT per-line checksum is one GreatBook added that the source workbook never had.
</Note>

## A receipt clears it

| Operation                     | Entry                                    |
| ----------------------------- | ---------------------------------------- |
| money in on a rail against AR | `Dr <rail GL account>` / `Cr 1100` (131) |

The receipt records a **settlement** row on its rail plus **allocation** rows saying which invoice it paid and how much of it.
Nothing about the invoice is edited: its `due` is *derived* as `total - allocated - advance_applied`, adjusted by any credit or debit notes against it.

Which GL account a rail lands on is a property of the rail, and each rail reconciles against **its own** external source rather than against one global cash figure.
The nine rails and their accounts are on [Settlement, rails and the AP/AR spine](/greatbook/capabilities/subledgers/settlement).

## Customer advances and deposits

| Operation                              | Entry                                             | Cash?  |
| -------------------------------------- | ------------------------------------------------- | ------ |
| customer advance or deposit in         | `Dr <rail GL>` / `Cr 2150` (131 customer advance) | yes    |
| apply that advance against an invoice  | `Dr 2150` / `Cr 1100` (131)                       | **no** |
| collateral we hold from a counterparty | `Dr <rail GL>` / `Cr 2350` (344)                  | yes    |
| collateral we place with one           | `Dr 1520` (244) / `Cr <rail GL>`                  | yes    |

The non-cash application is a real journal entry with no rail movement behind it.
The Close list carries `Σ|advance pool|` as a must-be-zero checksum precisely to catch an advance that was received and never applied.

<Info>
  A deposit **held** is supposed to be a non-zero liability, so it is reported as an *explainable balance* rather than a break.
  Reporting a legitimate balance as a break trains people to ignore breaks, which is why the Close list has two kinds of row.
</Info>

## Adjustment notes change the derived due, never the invoice

The original invoice is never edited.
A note references it, posts its own entry, and moves the *derived* outstanding.

| Shape                                                 | Entry                                                         | Effect on the outstanding |
| ----------------------------------------------------- | ------------------------------------------------------------- | ------------------------- |
| **AR credit note** - we reduce what the customer owes | `Dr 4090` (521 contra-revenue) / `Dr 2100` (3331) / `Cr 1100` | lowers it                 |
| **AR debit note** - we increase it                    | `Dr 1100` / `Cr 4000` (511) / `Cr 2100`                       | raises it                 |

`due = total - allocated - advance_applied + Σ(debit notes) - Σ(credit notes)`.

Two checks guard a note against what the original actually carried: its quantity gap may not exceed the original's quantity, and its VAT rate must match the original's.
Both are described in full on [Adjustment notes](/greatbook/capabilities/subledgers/adjustment-notes), with the other two shapes on [Adjustments, FX and consolidation](/greatbook/gl/rules-adjustments-and-fx).

## Factoring: the distinction is derecognition

Selling a receivable and borrowing against one look identical in the bank account and are opposite in the ledger.

| Kind                       | Entry                                            | Does the AR stay?                                 |
| -------------------------- | ------------------------------------------------ | ------------------------------------------------- |
| **recourse** factoring     | `Dr <rail>` / `Cr 2400` (341 facility)           | **yes** - this is secured borrowing               |
| **non-recourse** factoring | `Dr <rail>` + `Dr 6210` fee (635) / `Cr 1100` AR | no - the receivable is sold, its due goes to zero |

Getting this backwards either hides a liability or reports revenue-backed cash twice.
The Close list polices it as its own family, tying to the AR sub-ledger.

## Intercompany invoices mirror

| Side       | Entry                             |
| ---------- | --------------------------------- |
| the seller | `Dr 1100` (131) / `Cr 4000` (511) |
| the buyer  | `Dr <expense>` / `Cr 2000` (331)  |

The two are expected to eliminate on consolidation.
Current consolidation reads keep each side as independent evidence, so a missing or mismatched half stays visible rather than being treated as a proved pair.

## Accrued and deferred revenue

| Situation                           | Account                           | VAS  |
| ----------------------------------- | --------------------------------- | ---- |
| earned, not yet billed              | `1110` accrued revenue (unbilled) | 1388 |
| billed or collected, not yet earned | `2300` deferred revenue           | 3387 |

Both are moved by the Accountant's adjusting entries at close, through the human-approved posting gate like every other entry - never by a direct write.

## Where it is enforced

| Concern                                                  | Code                                                                                               |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| `create_invoice`, `receive`, customer advances, deposits | `backend/app/logics/finance/settlement.py`                                                         |
| the four note shapes and their two guards                | `backend/app/logics/finance/adjustments.py`                                                        |
| factoring and the recourse distinction                   | `backend/app/logics/finance/loans.py`                                                              |
| intercompany mirroring                                   | `backend/app/logics/finance/consolidation.py`                                                      |
| output VAT register lines                                | `backend/app/logics/finance/tax.py`                                                                |
| the ties                                                 | `close_checks.ar_control_tie`, `receipt_crossfoot`, `so_advance_pool_settles`, the output-VAT pair |

## The test that would fail if it broke

`backend/tests/test_settlement.py` and `backend/tests/test_close_checks.py` drive the AR spine and its tie-outs against a real migrated Postgres.
`backend/tests/test_loans.py` covers the recourse versus non-recourse split, including that a non-recourse advance takes the invoice's derived due to zero.

<Warning>
  The document path posts `creates_ap` only.
  An AR invoice reaches the ledger through `create_invoice`, not through the Bookkeeper's document lane - so a *sales* invoice uploaded as a document is classified, filed and reviewable, but its posting rule is not yet written.
  That is stated the same way everywhere in these docs: what is not built is named, not implied.
</Warning>

## Related

* [Payables and input VAT](/greatbook/gl/rules-payables) - the mirror family, in full
* [Payments, rails and treasury](/greatbook/gl/rules-money-movement) - what a receipt's rail row means
* [Adjustment notes](/greatbook/capabilities/subledgers/adjustment-notes) - the immutability feature that replaces editing a document
* [Loans, treasury and factoring](/greatbook/capabilities/subledgers/loans-treasury) - the facility lifecycle