Guide

How to invoice clients from GitHub (step-by-step)

Your shipped work already lives in GitHub — merged PRs, reviews, links. Billing usually means retyping all of that into a separate tool: slow, easy to forget scope, and weak proof for clients.

This guide walks merged PR → invoice → payment with less friction than billing from memory alone.

Why invoicing GitHub work is harder than it should be

Most invoicing tools were not built for developers. They assume:

• You track time manually
• You describe work manually
• Your work doesn't live in a version-controlled system

That leads to missed scope, unclear proof of work for clients, and invoices that take too long.

The core issue: your work (GitHub) and your billing (invoicing tool) are disconnected — so you reconcile two sources instead of one.

The better approach: invoice directly from GitHub work

Use merged PRs as the source of truth instead of reconstructing the week from memory.

1. Select merged pull requests
2. Assign a value to each
3. Generate an invoice
4. Send the invoice link
5. Track payment status

Step-by-step: from PR to paid invoice

Step 1: Identify completed work (merged PRs)

Start with merged pull requests for the billing period. Example titles: "Payment integration", "Fix webhook retry logic", "Refactor auth flow". Those are your deliverables.

Step 2: Decide how you charge

Keep pricing rules simple and repeatable:

• Flat rate per feature
• Hourly converted to a fixed amount for the period
• Milestone-based billing

Step 3: Create the invoice

Prefer generating line items from PRs instead of retyping GitHub into another tool. Example structure:

Development work — April 2026

PR #142 — Payment integration — $150
PR #145 — Webhook fixes — $80
PR #148 — Auth refactor — $120

Total: $350

Step 4: Send the invoice

Send your invoice link by email or Slack so your client can review work and pay securely — by card, PayPal, or bank transfer — without mailing PDFs back and forth.

Step 5: Track payment status

You need clear states: sent, paid, overdue. Manual inbox tracking breaks first — automate status when payment completes.

Example workflow

Instead of a single line like "Development work — $300", list recognizable PRs with a payment link. Clients see scope tied to real deliveries, which reduces disputes.

Common mistakes developers make

1. Vague invoices. Generic descriptions hide scope; tie lines to PRs when possible.
2. Forgetting work. Memory billing misses commits — GitHub already lists what merged.
3. Overcomplicating pricing. You rarely need a full accounting setup to bill freelance milestones.
4. Generic invoicing tools. Double entry: once in GitHub, once in billing — unless billing reads from GitHub.
5. Chasing payments manually. Send from a system that tracks reminders and status instead of only your personal inbox.

A simpler way: GitPay

GitPay is built for merged PRs → invoice → payment tracking: install the GitHub App on selected repositories, import read-only PR metadata (titles, dates, links — not source code), build line items, send your client the invoice link, and track status — without retyping GitHub into a second doc.

Closing

When invoice lines trace back to merged PRs, scope stays transparent and billing stays faster — same source of truth as your delivery.