Invoices and payments

An order’s lines say what the work is worth. Invoices say what the customer has been billed, and payments say what they’ve paid. YoPrint keeps all three on the sales order.

What an invoice holds

An order can have several invoices, such as a deposit invoice and a final one. Each invoice bills some of the order’s lines, and adds what only an invoice carries: shipping fees, discounts and tax.

• Sales order
  • Invoice, numbered like other documents, with four kinds of line
    • Billed lines, each pointing at one of the order’s lines
    • Shipping fee lines
    • Discount lines
    • One tax line, from the team’s tax preset, the automatic sales tax lookup, or set by hand
  • Another invoice
  • Payments, recorded on the order

A billed line points at an order line, so billing never retypes what was sold.

A customer who is tax-exempt isn’t charged tax. In the US, a team can turn on automatic sales tax, which looks up the rate for the address.

Auto Invoice

With Auto Invoice turned on, YoPrint makes and maintains the order’s invoice itself, adding lines as the order changes. You can’t change the quantity or price of a line on that invoice, and the order refuses invoices you create yourself: change the order line, and the invoice follows. You can still set the invoice’s tax yourself. Once you do, YoPrint stops managing the tax line.

How the balance works

The order’s lines aren’t owed until they’re invoiced. What the customer owes is what’s been invoiced, minus what they’ve paid:

1. Invoicedinvoiced_total: billed lines, shipping and tax, less discounts
2. Paidpaid_amount: the payments recorded on the order
3. Balance dueorder_balance_due

invoiced_total and order_balance_due are decimal pairs (value ÷ 10^dp). paid_amount is in thousandths (300000 is 300.00).

You want	Read on the order
What the order’s lines are worth	order_item_cart_total: price × quantity, before tax, shipping and discounts
What’s been billed	invoiced_total, with its parts in invoiced_order_item_subtotal, invoiced_shipment_subtotal, invoiced_tax_subtotal and invoiced_discount_subtotal
What’s been paid	paid_amount
What’s left to pay	order_balance_due

An invoice is paid when its payments cover its total. See Money and quantities for how to read each encoding.

Deposits and payment terms

Payment terms decide when the customer pays: whether there’s a deposit and how big it is, when it’s due, and when the full amount is due. Each team has a default, and a customer can have their own, which their orders take.

1. Deposit %From the order’s payment terms, such as 50%
2. BaseWhat the lines are worth: order_item_cart_total
3. Depositcalc_deposit_total, in thousandths

Once every line is invoiced, the base is the invoiced total instead.

1. Depositcalc_deposit_total
2. Paidpaid_amount
3. Deposit still duedeposit_amount_due

At 0 or less, the deposit is paid.

The due dates are on the order, not on each invoice: deposit due and full amount due.

How customers pay

Every payment belongs to an order. The ways it can arrive:

Way	How it happens
Recorded payment	The shop records money it already received, such as cash, a check or a bank transfer, with a payment method and a reference. In the web app: Record payment.
Card payment	Charged through the team’s payment gateway (Stripe, PayPal, Square or Authorize.Net): by the customer in the Customer Portal, or by the shop in the web app. Gravity Payments is being retired: only teams that already use it can still take payments with it.
Square Terminal	The customer pays in person, on the shop’s card reader.
Store credit	Credit on the customer’s account pays the order.

A recorded payment’s date, method, reference and note can be changed later, but not its amount: remove it and record it again.

Refunds go back to the customer’s card through the gateway, or are recorded by hand when the shop paid them back another way. The shop can also move paid money onto the customer’s store credit. Store credit is a balance on the customer’s account: a refund or the shop can add to it, and paying an order with it takes from it.

Payment links split a payment across the order’s invoices: one link records how much of a payment went to each invoice. The web app calls them payment allocations. Despite the name, a payment link isn’t a page the customer opens, and it moves no money.

Note

On a team connected to QuickBooks, YoPrint syncs the order’s invoices and payments there. See What a write also does.

Events

Event	When
payment_received.any_amount	Any payment is recorded on an order.
payment_received.deposit_amount	The total paid is exactly the deposit.
payment_received.full_amount	Nothing is left to pay.
payment.refund_issued	A refund is issued.
customer_credit.deposited, customer_credit.withdrew	The shop adds or takes out store credit by hand. Not when a refund adds credit, or a payment spends it.

There are no invoice events. To follow invoicing, read the order again after a payment event, or on a schedule.

In the API

Invoice an orderCreate invoices and their lines, change the tax, read the totals.

Take payments and refundsPayments, refunds, store credit and payment links.

Invoices referenceInvoices, with their line items under them.

Payments referenceRecorded payments, refunds, credit and gateways.