GitLab quarterly reconciliation and true-ups are the two ways GitLab bills users added beyond the seats a customer bought. GitLab subscriptions do not stop users from being added when the purchased seats run out, unless the customer turns on a seat control. Instead, GitLab reviews seat usage and “sends you an invoice for overages either quarterly (quarterly reconciliation process) or annually (annual true-up process)”.[2][4] Both processes are written into s.6 of the GitLab Subscription Agreement, which calls the extra users “Add-On Users”: “additional Users in excess of those that have been purchased under a Subscription”.[1]
Editions
Both processes apply to Premium and Ultimate on GitLab.com, Self-Managed and GitLab Dedicated.[2] Which one a subscription gets depends on how it was bought rather than on the tier.
| Purchase route | Process | Basis |
|---|---|---|
| Bought directly, credit card still linked or bought by invoice, 12-month term | Quarterly reconciliation | Billing for seat overages, Eligibility |
| Bought from a reseller or other channel partner, including cloud marketplaces | Annual true-up | Agreement s.6.7; Billing for seat overages |
| Multi-year or non-standard term, purchase order, Enterprise Agile Planning, public sector | Annual true-up | Billing for seat overages, Eligibility |
| Offline environment activated with a license file | Annual true-up, unless usage is reported | Billing for seat overages; Manage seats |
| Explicit opt-out by contract amendment | Annual true-up | Billing for seat overages |
| GitLab Flex | Neither; Flex billing terms apply | GitLab Flex |
The eligibility list is from the documentation retrieved on 2026-10-07.[2][9] The pricing FAQ says quarterly reconciliation became the “default option for new and renewing subscriptions after Aug 1, 2021”.[3] Catalog proof: Exclusions from quarterly reconciliation.
Metrics
Both processes measure the User through the Maximum users figure, the highest number of billable users reached in the period. The documentation says that under quarterly reconciliation “You pay for the maximum number of seats you used during the quarter.”[2] The billable roles behind that number are listed in GitLab billable users and seats.
Counting / floors
Quarterly reconciliation
Under s.6.6, at the end of each three-month period from the Subscription Start Date, GitLab produces a “Quarterly Add-On Report” of Add-On Users activated or used in that quarter. It then invoices them “on a prorated basis for the remaining portion of the Subscription Term”.[1] Two details reduce the bill. Add-On Users “will not be invoiced for the Quarter in which they were activated and/or used”, and the report runs only in the first three quarters of the term.[1] Add-On Users are charged at the List Price on the latest Order Form or web purchase unless a lower Effective Price was agreed.[1] Catalog proof: Quarterly add-on users are prorated for the remaining term.
The documentation works through an example. A customer buys 100 users at USD 100 each per year, and usage moves between 95 and 120:
| Quarter | Users | Charge under quarterly reconciliation |
|---|---|---|
| Q1 | 110 | 10 users x USD 25 x 3 remaining quarters = USD 750 |
| Q2 | 105 | None; below the new 110 baseline |
| Q3 | 120 | 10 users x USD 25 x 1 remaining quarter = USD 250 |
| Q4 | 120 | None; no charges for the fourth quarter |
The total is USD 1,000 under quarterly reconciliation. Under the annual true-up the same 20 extra users cost USD 2,000.[2] Each quarterly charge also raises the licensed count: after Q1, “You now pay a license for 110 users.”[2]
Invoicing. On GitLab.com, group owners and billing account managers are notified on the reconciliation date. On Self-Managed, billing account managers are notified six days after it. Seven days after the email the subscription is updated and a prorated invoice is raised; a card on file is charged automatically.[2] Self-Managed instances that are connected report their maximum users each quarter. If an instance cannot produce a quarterly usage report, the existing true-up model applies, and the documentation notes that “Prorated charges are not possible without a quarterly usage report.”[4]
Annual true-up
Section 6.7 applies when the customer bought through an Authorized Partner, or when GitLab cannot verify and generate a Quarterly Add-On Report or collect the quarterly payment. The customer must then provide an “Annual Report” of all Users within twelve months of the Subscription Effective Date. It must pay for Overage Users “for the previous twelve (12) months, at the then current List Price”.[1] The clause adds that Overage Users “shall not include any pro-ration, set-off and/or deduction to account for term of use, or otherwise”.[1] A user added in the eleventh month is therefore charged for the whole year, which is why the documentation’s example costs twice as much under the annual process.[2] The pricing FAQ gives the same rule: at renewal the customer pays for the new user count “and you also pay the full annual fee for the 200 users that you added during the year”.[3] Catalog proof: Annual true-up is unprorated at list price.
Offline instances
Offline or firewalled Self-Managed instances cannot send usage data. Administrators export a license usage file listing the billable user count for each day of the period, and GitLab uses it “to manually process quarterly reconciliations and renewals”.[6] The documentation warns not to open the file before sending it, because that can make the submission fail.[6] Where some instances use Cloud Licensing and others a legacy file, GitLab receives seat data only from the Cloud Licensing instance and uses that for overages.[7] Catalog proof: Offline instances report usage manually.
Floors
The customer cannot report fewer Users than it originally purchased, and Add-On Users are co-termed with the subscription.[1] Overage is calculated on the period’s maximum, so removing users before the reconciliation date does not reduce the invoice.[4] Catalog proof: No reduction of users during the term; Overage is measured on maximum users.
Renewal
Section 4.2 sets a twelve-month Subscription Term that renews automatically for further twelve-month terms. Each renewal keeps the same User licences, usage-based commitments, tier and subscription-based Supplemental Services, “plus any Add-On Users activated and/or used during such Subscription Term”.[1] To avoid that, either party must give notice at least 30 days before expiry. The customer can opt out in the Software interface or in writing at any time from the start date until that deadline.[1] The then-current List Price applies to renewal terms unless agreed otherwise, and GitLab may raise fees or offer different pricing if the customer reduces User licences.[1] Catalog proof: Automatic renewal includes add-on users.
The documentation adds that “Seat counts do not decrease automatically at renewal time.” When billable users exceed the subscription quantity at an automatic renewal, the seat count rises to match.[5] Renewing for fewer seats needs a manual renewal, which the Customers Portal opens only 15 days before expiry. The renewed seat count must be at least the number of billable users at that time.[5] The seat documentation warns that renewing through GitLab Sales for fewer users than are active creates an overage: renewing 20 active users as 15 seats incurs a charge for five.[4] Outstanding Overage Users must be paid before the subscription can be renewed.[1] Catalog proof: Auto-renewal raises seat count to billable users; Overage must be paid to renew.
Audit
Separately from the reconciliation processes, s.5.3 lets GitLab “verify electronically (or otherwise), and generate, or (ii) require Customer to generate and provide, reports” on installation, access and use. The customer must keep Customer Records during the Agreement and for two years after.[1] With 30 days’ written notice, during business hours and under confidentiality, GitLab may have an independent auditor check those records, but “only to verify the amounts payable”. Any underpayment is due with late fees, and the customer bears the audit cost if underpayment exceeds 5% for the audited period.[1] Unpaid fees carry a finance charge of 1% a month or the legal maximum, if lower.[1] Catalog proof: Usage verification and audit.
Virtualization & partitioning
Reconciliation counts users, not hosts. When one activation code covers several Self-Managed instances, GitLab takes the instance with the highest billable user count and uses it “for Quarterly Subscription Reconciliation and Auto-renewal (if enabled)”.[7] Catalog proof: One activation code for several Self-Managed instances.
Cloud / BYOL
Seats bought through the GCP and AWS marketplaces count as reseller purchases. Such customers cannot add seats in the Customers Portal and are excluded from quarterly reconciliation, so their overages are trued up annually.[4][2]
Programs
Quarterly subscription reconciliation and the Annual true-up are the two catalogued processes, alongside the Subscription Term and automatic renewal. GitLab Flex replaces both: “The standard add-on user and overage user billing processes do not apply to Flex.” Under Flex, seats are instead charged each month at the highest count reached.[9] Promotional Premium subscriptions sold in 2024 and 2025 invoiced Add-On Users quarterly at the discounted rate. Where GitLab could not verify them quarterly, an annual true-up applied at the list price.[8] Catalog proof: Flex replaces add-on user and overage billing.
Out of scope
This page does not cover GitLab Credits overage (on-demand credits), which is billed monthly in arrears; see GitLab Credits, Duo and Flex. Contracts signed before 2026-01-12 are governed by earlier versions of the Subscription Agreement listed in GitLab’s agreement history, and their true-up wording may differ.[10]