merge: P4b S6, paying on terms (branch S6, 6c4480cd)

The third of the paused branches: Ledger::settle with discounts and the
processor's fee (kernel::settle, Kani settle_is_exact, Lean
settle_posts_a_document_step), books.receive_payment and books.pay_bill
with applications, books.bills_due, the agings' detail and tie-out, the
aging exports and the CPA package's aging CSVs, the handlers in
tools/settlements.rs. Twelve files conflicted with the S4.4 and S5
merges, resolved as plan 8.0.2 says: both routers; both test appends
(the shared match arm in arap_standing.rs spliced into both tests; the
shared `.unwrap()` in store.rs); the scope table at 124; one
invoices-and-bills handbook (S5's send step 1 with S6's steps 2, 3, 5
and procedures) registered once; docs/mcp-interface.md with S4.4's
create docs and S6's payment docs; S5's law renumbered 35 and S6's 36
(S1's is 34); the parity rows and sections of both. S6's wire tests
create their bills as S4.4's contract now requires (confirmed, the
vendor's number, a line account, the vendor's invoice uploaded) and live
in their own module beside S4.4's tests.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HS8WZziDnyxunC23MUxrLp

crates/ledger-mcp/handbook/format-upgrade.md

@@ -6,3 +6,4 @@
 - Only the owner can agree to the upgrade, with the owner passphrase: in the app, which asks each time it opens the books, or with `wanderbooks books upgrade ID` in a terminal. No tool can, and you never ask for, take or type the passphrase. Tell the human, in plain words: the books wait for their go-ahead, what was refused, and that saying no keeps the books working as they are.
 - Before it upgrades, the server makes a backup of the books, their vault and keys included, and proves it whole; a backup that can't be made or proven upgrades nothing. Then the books move to the new format in one step, on the record.
 - After the upgrade an older version of wanderbooks can't open these books; the backup made first keeps them as they were. Going back is the owner's choice, never yours.
+- This upgrade is `documents_v2`: invoice numbers, terms and line accounts (S4), sent records (S5), payments that settle several documents with early-payment discounts and a processor's fee (S6), and write-offs (S7). Until it is given, those writes are refused and everything else works as before.

crates/ledger-mcp/handbook/invoices-and-bills.md

@@ -7,7 +7,7 @@ own figures are read from the ledger lines tagged with it, never kept on
 the document: a reversed payment, a void or a write-off comes out right
 without another copy to correct (B-38).
 
-## Sending an invoice
+## 1. Send an invoice
 
 - The books never send mail, and never say they did. To send an invoice,
   create and post it (`books.create_invoice`), hand its PDF to the human
@@ -26,3 +26,60 @@ without another copy to correct (B-38).
 - A void invoice can't be marked sent: it should never have reached the
   customer. An invoice already open, partly paid, paid or written off can
   (a copy for the customer's records, a reminder).
+
+## 2. Record a customer payment
+
+- Ask for the date the money arrived, where it landed, and what it paid.
+  One deposit may settle several invoices of the same customer: pass
+  `applications` with each invoice and its cash amount.
+- Record how it moved (`instrument`) and the processor's or bank's
+  reference. The books record payments; they never collect them.
+- If the customer paid more than the invoices owe, the payment is
+  refused: record the excess as a plain entry to 2300 Customer Deposits
+  (no role) and apply it when the work is invoiced (D-49, A-12).
+- A check or note marked "paid in full" of a disputed amount earns the
+  UCC §3-311 warning. Record only the payment; a lawyer or the payer's
+  agreement settles the rest.
+
+## 3. Pay a vendor bill
+
+- Ask for the date, the account it left, and which bills it pays. One
+  payment may settle several bills of one vendor (`applications`).
+- Record the method and the reference. A card payment is tagged as card
+  and stays out of 1099-NEC (D-40).
+- Use `books.bills_due` for what is due and when, with each vendor's
+  early-payment discount window.
+
+### Taking an early-payment discount
+
+- A bill on "2/10 net 30" takes 2% off if paid within ten days. Pass the
+  discount beside the cash (`discount`); the books post the gross method:
+  the bill is credited in full, the discount goes to Purchase Discounts
+  (6995), and the bank gets the rest.
+- A discount at most the terms allow and dated on or before their
+  discount date needs no reason. A larger or later one needs
+  `discount_reason` (a vendor who honours it anyway); it is journaled.
+- A bill with an asset or prepaid line refuses a discount: record the
+  bill net of the discount, or reclassify with an entry Dr 6995 Purchase
+  Discounts / Cr the asset account (D-49). Never split the discount across
+  the asset lines.
+
+## 5. A processor's fee
+
+- The books never charge or collect; a processor does, and keeps a fee.
+  Pass `fee` on `books.receive_payment` (amount, and optionally the
+  expense account and the processor's vendor).
+- The entry is gross: Dr the deposit account the net, Dr the
+  processing-fee expense the fee, Cr Accounts Receivable the gross (A-4).
+  Only cash movements count toward a 1099, so the fee is not a payment to
+  the processor.
+
+## A replacement payment arrives before a bounce is known
+
+1. Park it: a plain entry Dr the bank / Cr 2300 Customer Deposits (no
+   role), described with the customer and what it is for.
+2. When the first payment bounces, reverse it (`books.reverse_entry`)
+   dated the bounce day; it un-pays its invoices.
+3. Apply the parked money with `books.receive_payment`,
+   `deposit_to: "2300"`, dated on or after the bounce, against the
+   invoices it pays. The 2300 balance returns to zero.