Invoices are Flint's receivables resource. Every invoice is backed by an order: create one from an existing open order, or use quick pay input and Flint creates the backing order internally. A draft's snapshot.merchant_display_name shows your current business name. When you send an invoice, Flint freezes the customer-facing billing content, including that name, into a snapshot, issues a stable, revocable hosted invoice link, and emails the recipient.
- draft moves to open on issue
- draft moves to void on void
- open moves to paid on full payment
- open moves to partially_paid on partial payment
- partially_paid moves to paid on balance paid
- open moves to uncollectible on write off balance
- open moves to credited on credit balance
credited is the one status that can move backward. Credit reaches an invoice through a credit note, and reversing that allocation reopens the invoice to open or partially_paid. paid, void, and uncollectible are final.
An invoice moves from draft to open on send, then to partially_paid or paid as money comes in, uncollectible if you write the balance off, credited if a credit note closes it, or void if you cancel it. Collection can be online (an invoice-owned hosted checkout session for card payment) or offline via manual payments for checks, cash, wires, and other external methods. Delivery attempts, reminders, activities, and PDFs are all tracked on the invoice itself, and payment activity publishes webhook events.
Issuing an invoice also schedules its follow-up. Flint sends reminders on the cadence in invoices.reminder_policy, marks the invoice overdue, raises a late fee notice when the payment terms carry one, and retries a saved card on invoices.autopay_retry_policy. Set late_fee_policy.application_mode on a payment term to automatic to apply its fee after the grace period. The default is manual, which emits the notice without changing the balance. Automatic fees apply once per invoice or installment, wait for resolving payments, and send a buyer notice when invoice email delivery is enabled. Changes to a payment term affect future invoices only. POST /v1/invoices/{invoice_id}/late-fees also assesses the frozen policy onto the balance, and POST /v1/invoices/{invoice_id}/late-fees/{invoice_late_fee_id}/waive waives the unpaid remainder. Each assessment lands in late_fees with its calculation inputs, assessed amount, and outstanding amount, and the issued line items, tax, and total stay fixed. reminders_paused reports whether the automatic reminders are paused, and reminders_paused_at records when. After issue, reminders_paused is the only field PATCH accepts: set it to true to pause reminders on an open or partially paid invoice and false to resume them. Each line in snapshot.line_items carries an invoice_line_item_id, which is what a credit note credits.
See the Invoicing guide for an end-to-end walkthrough, Credit notes for correcting an issued invoice, and Payment links vs checkout sessions vs invoices for choosing the right collection surface.
Automatic tax narrows the payment schedule. An automatic tax invoice takes one payment for its full balance, and editing the backing order after issue blocks collection until you void and reissue. See Tax on an invoice.
Create an invoice with schedule_entries to author its payment schedule, or omit the array to use the default derived from its terms. On draft PATCH, include the invoice's last-read version as expected_version when replacing the schedule. Include invoice_schedule_entry_id to retain an entry and omit it to create one. Omission leaves the schedule unchanged, [] clears the authored schedule, and null is invalid. The complete schedule must satisfy the invoice's amount and due-date rules, with at most 14 entries. Scalar edits and schedule changes succeed together. A stale version returns INVOICE_DRAFT_CHANGED.
Manual payments on gift card purchase lines issue each card when its full price has been paid. Partial payments retain their contribution until a whole card can be issued. Invoice late fees do not fund gift card value. Reversing a manual payment removes the value backed by that payment. If that value has been spent or reserved, the reversal returns a conflict and the payment stays recorded. Gift card load responses identify a manual reversal through purchase_refunds[].order_manual_reversal_id.
Invoice responses include version. You can also send expected_version when issuing, voiding, marking an invoice uncollectible, setting reminders_paused, regenerating its public link, or recording or reversing a manual payment. Use the version returned by the latest successful write for the next edit.