Blog

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

If you're a freelance developer, most of your actual work lives in GitHub — pull requests, commits, issues, and reviews. When it's time to get paid, you still open an invoicing tool, remember what you worked on, manually write descriptions, and send an invoice separately. It's disconnected, slow, and easy to get wrong.

This guide walks through a practical workflow from merged PR → invoice → payment, with less friction than typing everything from memory.

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 → flexible payments → tracking: connect GitHub, select merged PRs, generate the invoice, send your client the link, and track payment — without duplicating GitHub into a second system for line-item drafting.

Closing

Your work already exists in GitHub; invoices are clearer when they come from the same place. If you align workflow, you spend less time billing and clients see transparent scope.