Paid is paid, however it arrived.

The hosted invoice page offers the payment options frozen in the invoice's payment policy, and it always collects the full remaining balance. Anything you collect outside that page, such as a check, wire, cash, or bank payment taken elsewhere, is recorded against the invoice with the manual-payments endpoint. Both update outstanding_money and status, which is why a partly-paid invoice is a normal state rather than a workaround.

Offline. The hosted page has no amount field and always asks for the whole remaining balance, so a partial payment happens when you record one: manual payments accept any positive amount up to the balance. Record $800 against an $1,836 invoice and it becomes partially_paid with $1,036 still collectible online.

Reverse it. The reverse endpoint takes an amount and a reference and puts the balance back, and it works on a paid invoice as well as an open one, so a check that clears an invoice and then returns unpaid reopens it correctly. It can only undo offline amounts, never card money, and it cannot exceed what was recorded manually.

On the schedule you write. reminder_policy is a list of day offsets from the due date, negative ones fire before it, and the invoice freezes that list when you send it so a settings change never rewrites a receivable already in flight. Leave the list empty and nothing sends automatically. pause-reminders stops the cadence on one invoice the moment a customer replies, and send-reminder still works while it is paused.

Yes, and they are different rows. Every send and reminder is logged as a delivery attempt with a status and, when it fails, an error message, and invoice.delivery_failed fires on a bounce. The first time the customer opens the hosted page stamps viewed_at. So "sent Tuesday, opened Wednesday, still unpaid" and "never reached their inbox" are two different reads rather than the same silence.

Refund the order the invoice describes, item by item, with the standard refunds endpoint. There is no invoice-specific refund call. The invoice tracks refunded_money and refund_status as their own axis, so paid never moves backward and reporting can tell a settled invoice from a settled-then-refunded one.

A refund returns money that already settled. A credit note reduces a balance that has not been paid: it credits specific invoice lines, carries their discount and tax with them, and produces a numbered PDF for the customer's accounts-payable file. Allocating the credit draws down outstanding_money, and reversing that allocation puts it back, which is why credited is the one invoice status that can move backward.

No. This is US-focused collection: an itemized document, a hosted payment page, a PDF snapshot, and receivables state you can query. Government e-invoicing mandates, clearance models, and networks like Peppol are a dedicated compliance vendor's job, and pretending otherwise would be the expensive kind of wrong.