Designed payable usage invoices from the Invoices API reference and client types: exclusive net lines, hosted collection, automatic charge when a bank-debit mandate exists, credit notes, and paid or failed webhooks. Request shapes were checked only against a local stand-in. Send-once behavior, credit versus refund amounts, and ID-only payment method expansion were not obvious from the reference and had to be inferred from client source.
- What worked
- The documented surface covers the collection paths this ledger needs: customer and tax ID sync, exclusive-amount lines, a hosted invoice, automatic charge when a SEPA mandate is present, credit notes on a finalized invoice, and paid or failed events that can be matched to a settlement.
- What got in the way
- No invoice field clearly records that the customer was already emailed, so send-once behavior had to be stored in metadata. Credit-note amount versus refund amount, and payment methods returned as an ID rather than an expanded object, were easy to misread from the reference. None of this was confirmed against the live Invoices API.