How do freelancers prove billable hours using GitHub PRs?
How do freelancers prove billable hours using GitHub PRs? Pair time logs with PR evidence, separate merge dates from work dates, and protect client information.
Freelancers substantiate billable hours by pairing contemporaneous time logs with GitHub pull requests that document the work performed; PRs alone do not prove time spent. For a 2026 invoice, connect each time entry to the relevant PR, task, or review discussion and describe the activity you billed. A merge timestamp records when work merged, not when you performed every billable activity.
Why this matters
Your client needs to reconcile the invoice with the work they authorized. A list of merged PRs helps identify delivered changes, but it leaves the duration and billing basis unexplained. A time log without task references creates the opposite problem: it records duration without enough context.
Start with the evidence your agreement requires, then choose tools for freelance developers to track billable work around that process. For your 2026 reporting, keep delivery history and time records connected without treating either as a substitute for the other.
How do freelancers prove billable hours using GitHub PRs?
Use a time log as the record of hours and GitHub PRs as supporting evidence of activity and delivery. Follow this sequence before submitting an invoice:
- Check the agreement. Identify the billing basis, approved activities, reporting period, and evidence the client expects.
- Record work when it happens. Capture the work date, duration, client, task, and a specific description.
- Attach relevant evidence. Reference the PR, issue, review discussion, or other record associated with the entry.
- Reconcile the period. Check work dates separately from merge dates and account for unfinished work.
- Review the report. Remove duplicate entries, explain shared references, and restrict confidential information.
The strongest billing record connects an agreed activity, a recorded duration, and a traceable work reference. None of those elements replaces the others. A detailed PR description strengthens the explanation of what changed; it does not establish how long the change took.
Check the agreement before choosing evidence
Read the contract, statement of work, or other agreed billing instructions before assembling a report. Look for what counts as billable work, how you should report time, and who accepts the invoice. Do not assume that a merged PR automatically satisfies those requirements.
Ask the client to clarify ambiguous activities before billing them. Debugging, planning, meetings, and code review need an agreed treatment just as implementation does. Keep the answer with the engagement records so you can apply the same rule throughout the project.
Record work separately from delivery
A useful time entry names the activity rather than merely saying development. Describe whether you implemented a change, reproduced a defect, reviewed feedback, or investigated a failing test. Attach the relevant reference when it exists.
Keep actual work dates intact. If you prepare a January 2026 invoice and a PR merges in February 2026, do not move the January work into February just to match the merge history. The time record and the delivery record describe different events.
Match references without counting work twice
The relationship between time entries and PRs is not necessarily one-to-one. A single task can span several sessions, and a session can involve several related changes. Use descriptions that make those relationships understandable without inflating the billed duration.
If multiple entries reference the same PR, identify the different activities or dates. If one entry covers several PRs, explain the shared task. Repeating a PR reference is not duplicate billing; repeating the same recorded work is the problem to check.
Which records should you use together?
Choose records according to the question they answer. A time log answers when you worked and for how long; a PR helps explain the change, discussion, and merge event. Neither should be presented as evidence of something it does not record.
| Record or method | Best for | What it contributes | Limitation |
|---|---|---|---|
| Time log | Recording billable duration | Work dates, durations, and activity descriptions | Needs task context and accurate entries |
| GitHub search | Occasional PR lookups | Locating relevant PRs and inspecting their history | Requires manual searching and review |
| Pulltally | Repeated merged-PR history checks | Browsing and summarizing merged PRs by month, organization, or personal repository | Merged history does not establish hours or capture all billable activity |
| Issue or review discussion | Explaining investigation and feedback | Context for decisions, requests, and review work | Discussion timestamps do not establish total working time |
For an occasional invoice, GitHub search and a clearly maintained time log are enough to assemble supporting references. Search for PRs you authored, narrow the repository or organization, and inspect the relevant period. Check individual records rather than assuming the result list explains the invoice.
A repeated monthly search is a different workflow. Pulltally helps you browse merged history without rebuilding the same manual lookup each time. Keep a separate time record: a monthly delivery summary remains a delivery summary, not an hours calculation.
What should a PR-backed billing report contain?
Give the client enough information to connect each billed activity to its supporting record. Keep the invoice readable; put detailed references in an accompanying report when the client accepts that arrangement. Agree on the format rather than adding unnecessary repository detail.
Use the following fields as a starting point, then adapt them to the engagement:
- Work date: When you performed the activity, not simply when the PR merged.
- Recorded duration: The time recorded for that activity under the agreed billing rules.
- Task description: A plain explanation of what you did and why it belonged to the assignment.
- Work reference: The relevant PR, issue, review discussion, or approved task identifier.
- Delivery status: Whether the work is in progress, awaiting review, merged, or otherwise completed.
- Exception note: An explanation for work with no PR, a cross-period merge, or a shared reference.
Write descriptions that distinguish activity from outcome. Investigating a defect and merging a fix are different events; either can appear in the report when the agreement permits it. Do not rewrite an investigation as a delivered fix merely because the invoice needs a concise description.
Keep supporting records consistent with the invoice period. If a report lists only merged work, label it accordingly so the client does not mistake it for a complete account of all activity. A clear scope statement prevents the report from claiming more than it contains.
Why the evidence needed for billable hours varies
The right supporting material depends on the engagement and the work performed. Use these factors to decide what to include, rather than applying a universal rule based on PR count:
- Billing basis: Hourly billing requires a duration record; milestone acceptance concerns the agreed deliverable.
- Agreed activities: Implementation, investigation, meetings, and review need the treatment established with the client.
- Delivery timing: Work and merge events can fall in different reporting periods.
- Repository access: A reference is less useful to a reviewer who cannot open it; agree on an authorized alternative.
- Work relationships: Shared tasks and PRs require descriptions that distinguish the recorded activities.
- Confidentiality: Reports must respect the client's restrictions on sharing repository information.
For an hourly engagement, resist the temptation to divide the invoice total by the number of merged PRs. That produces an allocation, not a record of actual working time. PRs differ in scope, and some authorized work never produces one.
For a milestone engagement, keep the focus on the agreed acceptance criteria. PRs can support a delivery explanation, but do not introduce an hours calculation unless the agreement calls for one. The billing basis should determine the report, not the records that happen to be easiest to collect.
How should you handle missing or disputed time?
If you missed a time entry, separate what you can verify from what you are reconstructing. Review the relevant task records, discussions, and calendar entries, then follow the client's agreed correction process. Do not present a reconstructed estimate as a contemporaneous timer record.
If a client disputes an entry, address the specific concern. Confirm the date, activity, duration, authorization, and supporting reference rather than sending a larger list of unrelated PRs. More delivery evidence does not resolve a disagreement about whether an activity was authorized.
Keep corrections visible in your own records. When you change a description or duration, retain enough context to explain the change if asked. The goal is a report the client can reconcile, not a retrospective story built from merge events.
How do you protect private repository information?
Share only the information needed for the billing review. A PR title, description, or discussion can contain confidential context even when you omit source code. Confirm who is allowed to receive the report before copying repository material into another system.
Pulltally uses read-only access to pull request metadata to support browsing and summarizing merged history. Signing in alone does not connect private organization repositories. Those permission boundaries do not replace your responsibility to follow client rules when accessing or sharing work records.
For your 2026 reporting process, check both access and audience: what a connected tool can read, and what the invoice recipient is authorized to see. If the recipient lacks repository access, agree on a permitted summary rather than exporting private discussions by default.
Can I calculate billable hours from PR timestamps?
PR timestamps do not establish billable duration. The interval between opening and merging can include review queues, waiting, and time spent on other work. Use recorded work sessions for hours and timestamps to explain the sequence of events.
Can I bill for work that has not merged?
Unmerged work belongs on an invoice only under the agreed billing terms. For authorized hourly work, describe the activity and its status rather than presenting it as completed delivery. For milestone billing, follow the agreed acceptance conditions.
Is a merged PR enough if the client accepts it?
A merged PR supports whatever reporting arrangement you and the client have agreed. Acceptance as a work reference still does not turn its timestamps into a duration record. Keep the distinction clear even when the client's reporting process is simple.
FAQ
Can GitHub pull requests prove how many hours I worked?
GitHub pull requests do not prove working hours on their own. Pair relevant PRs with recorded work dates, durations, and activity descriptions to support an hourly invoice.
What is the best way to connect time entries to PRs?
Add the relevant PR reference to each time entry and describe the activity performed. If several entries share a PR, distinguish the dates or activities so the report remains easy to reconcile.
Should I count PRs merged during the invoice month?
Count monthly merges when you need a delivery summary, not an hours total. Work performed during the invoice month can merge later, so reconcile work dates separately.
Can I bill for debugging that did not produce a PR?
Bill debugging according to the activities authorized by your agreement. Record the work and reference the relevant issue, investigation notes, or other permitted evidence rather than inventing a PR connection.
Does Pulltally track billable hours from GitHub?
Pulltally browses and summarizes merged GitHub PRs by month, organization, or personal repository. Use that history as delivery context, not as a measurement of billable hours.
Does signing in connect my private organization repositories?
Signing in alone does not connect private organization repositories. Access to pull request metadata is read-only; confirm your client's rules before connecting or sharing work history.
Should I send private PR discussions with my invoice?
Send private PR discussions only when sharing them is authorized and necessary for the billing review. Agree on a limited summary when the recipient does not need the underlying discussion.
One last thing
The merge date is often the least useful date for deciding when to bill hourly work. It belongs to the delivery history; your work dates belong to the time record. Before sending a 2026 invoice, check entries tied to PRs that crossed the reporting boundary in either direction.
Keep that check separate from judging performance. A tally of merged PRs describes part of your delivery history, not your productivity or the value of every task. Bill the work under the agreement and use PRs to make the explanation traceable.
