GitHub Copilot self-serve seats become paid before access

GitHub is changing how self-serve Copilot Business and Copilot Enterprise seats are billed for customers paying by credit card or PayPal. Starting with the new flow, GitHub says each new seat assignment will require payment before that user gains Copilot access; existing customers in that payment group move to upfront billing for assigned seats beginning October 1, 2026.

That turns seat assignment into a purchase event rather than an access change that finance can reconcile later. The practical job is to put approval before assignment, understand what happens when a seat is added or removed mid-cycle, and verify the first affected invoice without confusing seat cost with usage-based AI charges.

Who is affected, and when?

GitHub's August 28 announcement applies the stated changes to Copilot Business and Copilot Enterprise customers who pay by credit card or PayPal. GitHub plans to start reenabling new sign-ups in that self-serve group on September 1, 2026, after temporarily pausing new self-serve purchases in April.

For new seat assignments, payment will be required before the user gains access. For existing customers in the affected payment group, GitHub says the new billing behavior starts October 1. At the beginning of the next billing cycle, every assigned Business or Enterprise seat will incur an upfront charge.

This scope should stay explicit. The announcement does not say that October 1 is the effective date for every invoiced, sales-led, or contract customer. If your organization does not pay by credit card or PayPal, use the terms and billing notice for your account rather than importing this schedule.

What happens when a seat changes mid-cycle?

Seats added during a billing cycle will continue to be prorated from the assignment date through the end of that cycle. The meaningful change is sequencing: GitHub says the seat must be paid before access is granted, so an assignment request can no longer be treated as cost-free pending a later approval.

Removing a seat works differently. GitHub says revoking a seat does not produce a prorated refund, and the removal is reflected in the next monthly billing cycle. A seat removed just after renewal may therefore remain a paid seat for that cycle even though the user no longer has access.

Included usage can move with the partial seat period too. GitHub says included usage may be prorated across the month to align with seat-cost proration. “May” is important: do not calculate a guaranteed allowance from a seat fraction until the account's billing record shows how GitHub applied it.

The announcement says plan prices are not changing. It also says additional usage can still be purchased and that spend controls, usage tracking, and additional AI credits remain available. Seat charges and usage-based charges are therefore separate evidence lines even when they appear on the same account.

Why should approval move before assignment?

BaristaLabs interpretation: the access administrator is now operating a purchasing control in the affected self-serve flow. If a manager can request a seat, an administrator can assign it, and finance only sees the decision after the charge, then the company has placed approval after the commitment.

Move the evidence in front of the assignment. A request should identify the user, team, approved business need, cost owner, requested date, expected review date, and the person authorized to approve the purchase. The Copilot administrator should assign the seat only after those fields are complete.

Avoid making this heavier than the purchase warrants. A small business may need one accountable approver and a dated ticket rather than a full procurement system. The control is effective when an assignment cannot silently create an unowned recurring charge, not when the form has the most fields.

Use fields that let access operations and finance reconcile the same event:

Scroll sideways to see all 3 columns.

Field	Question it answers	Evidence owner
Requested user and team	Who will receive access?	Requester
Business need and review date	Why is the recurring seat needed, and when is that need reconsidered?	Manager
Cost owner and purchase approval	Which budget accepts the charge?	Approver
Assignment date and administrator	When was paid access created, and by whom?	Copilot administrator
Billing-cycle boundary	When must the keep-or-remove decision be made?	Finance or license owner

When should a seat be removed?

Revocation still matters for security and access, so do not leave an unnecessary seat active merely to use the remainder of a paid period. Remove access when the user changes roles, leaves the organization, or no longer has an approved need. The absence of a prorated refund does not justify retaining access.

Cost timing is a separate decision. Maintain a renewal view that shows the next billing-cycle boundary and the internal review date far enough ahead of it to make a deliberate keep-or-remove choice. For planned project endings, review the seat before renewal rather than discovering an unused assignment after the next upfront charge.

This recommendation does not change GitHub's billing rules. It aligns internal review timing with the documented fact that removal is reflected in the next monthly cycle and does not refund the current one.

How should finance verify the first affected invoice?

Start with a point-in-time inventory immediately before the billing-cycle boundary: assigned user, plan, assignment date, approval record, and cost owner. Capture a second inventory after the cycle begins. The difference should explain which seats renewed, which were added with proration, and which removals are scheduled to affect the following cycle.

Reconcile three quantities separately:

• assigned seats charged upfront for the cycle;
• mid-cycle seat additions and their prorated seat charges;
• usage beyond included allowances, if any.

Do not use total Copilot spend alone to decide whether a seat charge is wrong. Our article on Copilot tasks from Teams and their two usage budgets covers AI-credit and cloud-sandbox meters; those controls do not replace seat approval or renewal review.

If included usage appears prorated, preserve the allowance shown by GitHub alongside the assignment date and seat charge. If it does not match the team's expectation, ask GitHub to explain the account result rather than reverse-engineering a universal formula from one invoice.

Do not use a policy check as billing evidence

GitHub announced policy, retention, code-review, and billing changes together, but they do not share an acceptance test. A screenshot of an enabled Copilot policy does not prove that a seat purchase had an approver, and a repository's review-effort setting does not explain an invoice line.

Keep links to the separate retention decision and code-review effort decision in the rollout record, but give the seat ledger its own finance and access owners. Completion for this workstream means an approved assignment reconciles to the observed seat charge and renewal date.

What should be ready before October 1?

For an affected credit-card or PayPal account, the minimum useful preparation is an assigned-seat inventory, an approver before assignment, a cost owner for every seat, a review date before renewal, and an invoice check that separates seats from additional usage. Record any uncertainty about included-usage proration instead of presenting an estimate as a promised allowance.

GitHub has changed the order of operations: payment precedes access for a new self-serve seat. A sound internal process should follow the same order—approve the recurring purchase, assign access, review before renewal, and reconcile the observed bill.

BaristaLabs can review one Copilot seat workflow and connect the access request, purchase approval, billing owner, renewal timing, usage evidence, and offboarding decision without collecting payment details through the contact form.

Sources

• GitHub Changelog: “Upcoming changes to GitHub Copilot policies and billing”, posted August 28, 2026.
• GitHub Docs: “Quickstart for GitHub Copilot”, accessed August 30, 2026.

GitHub controls the product scope, rollout dates, billing behavior, and included-usage treatment described in those sources. BaristaLabs supplies the operating interpretation and workflow recommendations.