Invoices

Invoicing runs in two directions in GIG: sending one, from a receivable line item on a project's budget, and receiving one, through Finance → Payables. This page covers both.

Sending an invoice

An invoice is sent against a line item, not created from a blank form. On a project's Finance page, a line item typed Receivable with at least one entity attached goes through three steps before Stripe will send anything:

1. Send for Approval. This asks each entity attached to the line item to approve the amount they've been billed.
2. Finance Lead or Owner sign-off. Once every entity has approved, the budget's Finance Lead (or an Owner) has to approve the line item a second time, from their Finance → Lead Desk approvals queue — entity agreement alone is not enough to authorize money leaving or entering the org.
3. Send Invoice. Only an Owner or the project's Project Lead can do this — Admin is deliberately excluded. It sends one Stripe invoice per entity attached to the line item (a split receivable becomes several invoices, one each), and Stripe emails each one directly to the entity. Each invoice bills that entity's share with its tax on a line of its own, so its total is the same, to the cent, as GIG's PDF and the Aging report for that share. The invoice is due on the line item's own due date if it has one, otherwise on your organization's payment terms, and the line item records the same dates, so it shows up on Aging and is flagged when it's late.

Payment terms are set in Finance → Settings by the Owner: the number of days from the day an invoice is issued to the day it's due, 30 unless you change it, 0 for due on receipt. Stripe is never asked for less than a day, so an invoice due today or earlier is due the next day in Stripe's email.

If your organization collects money outside Stripe — an e-transfer, for instance — use Issue instead of, or alongside, Send Invoice. It gives the line item a number from a gap-free sequence and stamps today's date in your organization's timezone, then lets the due date follow your organization's payment terms, unless you typed a due date of your own. Nothing is charged and nothing leaves the building. A number is only ever used by an invoice that was actually issued: clicking Issue twice, or from two tabs at once, hands back the same number, and an Issue that is refused (a due date that has already passed, for instance) uses none. An org on Stripe typically presses both, Issue first for the paper trail and Send Invoice to actually collect — Stripe's invoice is then due on the same day as GIG's. An org billing by e-transfer presses Issue, then records the payment when it arrives (below).

Deleting a line item never cancels a Stripe invoice already sent for it — GIG warns you of this in the delete confirmation when it applies, and you'll need to void or cancel that invoice from within Stripe yourself.

Tracking

The line item's status carries the invoice through its life: planned, then invoiced once at least one Stripe invoice has gone out or a number has been issued, then paid once Stripe confirms the corresponding payment or someone records it, or cancelled if it is voided. Once a number exists, a download icon next to the status opens GIG's own PDF for that invoice — separate from the "view in Stripe" link that appears once a Stripe invoice has actually been sent for it. A receivable split across several entities has no single PDF to download from the line item row; each entity's own copy is on Finance → Reports → Aging instead.

To refund an invoice after it's paid, use the Refund button on the matching row in Finance → Payments — see the Payments page in this help centre for how refunds work.

Recording a payment, or voiding

When a client pays outside Stripe — an e-transfer, a cheque, cash — press Record payment on the issued line item and enter the day the money arrived, how it was paid and, if you like, a reference. The invoice leaves the Aging report, stops being chased, and counts as paid income on that day. On a receivable split across several clients, each client pays their own share: record each one from their row on Finance → Reports → Aging, and the line item turns paid once the last share is in. An invoice still open at Stripe records its payment through Stripe; if the client paid another way, void it in Stripe first.

An issued invoice that will never be paid — billed in error, replaced, or written off — is voided, not deleted. Void keeps the invoice and its number and marks it cancelled, so your numbering has no gap. An invoice with a payment already recorded against it can't be voided.

Only an Owner or the budget's Finance Lead can record a payment or void an invoice, the same people who sign money off.

Once an invoice is issued (or paid), its amount, tax, type and who it bills are locked, because the PDF, the reminder and the aging report all quote them under that number. To change what is owed, void it and raise a new one. Its description and dates stay editable.

Chasing an overdue invoice

GIG never emails a client automatically. Once an issued invoice's due date passes, your organization gets an in-app notification at 1, 7, 30, 60 and 90 days late — a flag for you, not a message to them — and it opens that project's budget. A due date typed on a receivable that hasn't been issued or sent yet doesn't count until it is: nobody has been billed, so Aging keeps it under Not yet due and nothing is chased. To actually email the client, open Finance → Reports → Aging — visible to Owners and Admins, and only once Get paid is turned on in Finance settings — and press Remind on their row. The button only appears once an invoice is genuinely overdue, and the reminder is sent from your organization's own address and logged against that invoice. There's no scheduled reminder email, by design: GIG's outgoing mail shares one sending domain, so an automated dunning run that a spam filter didn't like would hurt every organization's deliverability, not just yours — a person has to press the button each time.

Payables and invoice intake

Finance → Payables (it was called Invoices & Expenses) is the queue of what people have sent you: invoices and expense claims from /profile, and invoices that arrive through the intake form. Approving one books a payable on the budget you pick; Open shows the file, or the receipt link when the document points at one kept elsewhere.

Invoice intake is a slider in Finance → Settings (owner or admin; the gear at the bottom of the finance rail opens it). Turning it on builds and publishes a form in the Forms module — name, email, invoice number, amount before tax, HST, what it is for, the season, and the invoice file — and gives you a link to hand to suppliers and crew, in the shape your-org-name/payable/<form>. Payables shows a Share intake link button while intake is on, so the link is one click away where you review what comes in. Every submission to that form lands in Payables as a submitted invoice with the amount and HST split, the season matched to a budget when the name still matches, the payee matched to your directory by email when there is exactly one, and the file copied into finance storage. Turning it off unpublishes the form; turning it back on brings the same link back.

You can edit the form like any other. Keep the name, amount and file fields: those are what the hand-off reads. Relabel or reorder anything else.

Deleting the person a payable belongs to

If you delete the person a payable's money was attributed to, the payable itself is untouched — it keeps the payee's name and email exactly as they were at the time, even though the record they came from is gone. That's deliberate: a season's payment history should survive a later cleanup of your people directory the same way a gig's roster does.