Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Financial Planning & Analysis

On this page

Financial Planning & Analysis @ GitLab

What is purpose of FP&A @ GitLab?

  1. Help drive GitLab’s business value
  2. Facilitate execution of GitLab's strategy
  3. Ensure financial and operational goals of GitLab are defined, documented and achieved
  4. Evangelize awareness of strategy and each departments role in achieving it
  5. Ensure sound decision support

How GitLab’s FP&A plans to get there….

  1. Manage the budget and planning processes for GitLab's operating plan
  2. Build and maintain an integrated financial model that projects performance into the future
  3. Measure, track and report on GitLab’s KPIs
  4. Constantly look for opportunities to improve performance
    • Process Improvements
    • Analytics
    • Education

GitLab's Operating Plan vs Integrated Financial Model

Operating Plan

GitLab's operating plan is a guideline to understand how much capital it needs and how the capital will be consumed. The operating plan helps GitLab answer questions like "how fast can we hire and when?" The operating plan consists of three main components: the revenue model, the rolling 4 quarter forecast and the budget. The operating plan can also be considered a bottoms up plan.

Integrated Financial Model

GitLab's integrated financial model is synonymous to its operating plan, but the integrated financial model is based soley on business drivers. The integrated financial model dynamcially answers questions like “What are our limits in comparison to the total addressable market?” and provides "What-if" scenarios. The integrated financial model also helps set the long term profitablity goals. GitLab has established business drivers in each function of the business and continues to refine them to ensure its tracking accordingly. The integrated financial model can also be considered a tops down plan.

Operating Plan

Forecasting Growth Using a Growth Persistence Model

Scale Venture Partners developed a Growth Persistence Model based on research on private and public software companies. The Persistence Model shows that ARR growth rates typically decline year over year, with each year’s growth being, on average 85% to that of the preceding year. We use this methodology to set our growth targets.

Operating Plan Diagram

alt text

Planning @ GitLab

Making Changes to the Plan to Optimize for Growth

Our Plan is intended to ensure that the Company has sufficiently considered what is required to support the Company's financial goals. The Plan ensures that there is accountability across all divisions that can be measured. The Plan is not intended to represent a cap on what we can invest in support of maximizing the growth of the Company. We encourage our team members to actively seek opportunities that will help us grow faster. Those growth initiatives will be evaluated, as follows:

  1. If the investment will allow us to exceed our IACV plan by at least an equal amount in the current year we will do it. The e-group will be informed of the increased spend and anticipated impact.
  2. If the increased spend will allow us to exceed our IACV targets next year then we will quantify the impact and raise our financial guidance for the following year. The e-group will review these investments and will, in some cases, request board approval for relief against current year planning targets.
  3. If we need to exceed spend to achieve our current plan we should review as an e-group and inform the board. We won't necessarily get plan relief unless there are extenuating circumstances but we will do what is right for the business.

Rolling 4 Quarter Forecast

GitLab creates an annual Plan which establishes our financial objectives for the coming fiscal year and is used for measurement of the Company's ability to achieve goals. Things move quickly and our forecast needs to iterate quickly to keep up with the business. Accordingly, we run a rolling 4 quarter forecast process. This means that we are always looking out a minimum of 12 months when projecting revenue and expenses, and we update those forecasts at least once per quarter. We plan our expenses at a high level (e-group) and we expect this group to make prioritizations and trade-offs while remaining accountable against the plan parameters. By reforecasting quarterly, we can quickly evaluate and incorporate new initiatives into our forecasting model. That being said, we do follow an annual plan to set our goals and measurement for our top-level targets of revenue, profitability and expense management.

Tips - Rolling 4 Quarter Forecast

Note: During the last quarter of the year, GitLab runs a 5 quarter forecast that aligns with it's annual planning efforts.

Monthly Investor Update

Each month we send to our investors an update no later than the 10th day following the end of the month. For further reference see our blog post.


  1. Thanks
  2. Asks
  3. Key Metrics
  4. Lowlights
  5. Highlights
  6. Expectations (next month)


  1. On the 1st day of the month, the FinOps lead prepares a draft of the previous months investor update in a google document and posts in the #investor-update slack channel.
  2. On the same day the draft is added to the #investor update slack channel, the FinOps lead will @mention e-group members with asks for topics related to the investor update agenda.
  3. The e-group members will have no later than the 9th of each month to review and add input.
  4. No later than the 10th of each month the will CEO send the update to the investor mailing list.
  5. Once the investor update is sent to the investor mailing list, the FinOps lead will add the current investor update to the #investor-update slack channel, along with highlight commentary on GitLab's operating metrics.

Relevant Locations for Investor Update Process

Revenue Model & Metrics Tab within the Financial Model

1: Sales Metrics 2019 Monthly Metrics

2: Periscope

3: Metrics Report (SFDC)

4: All Pipeline Report (SFDC)

5: Late Stage Report (SFDC)

6: Orders Processed Report (SFDC)

7: Revenue Spreadsheet sent from Controller

8: Cash Flow Forecast (Accounting Will Send Over – typically within the 4th of the Month)

9: Pingdom

10: LTV for Metrics

11: BambooHR

12: Zendesk

13: Snowflake

14: Sales Pipeline Analysis

Once Metrics & Financial Model Are Completed for Investor Update Process

Budgeting @ GitLab

Out of Budget Business Case

In the event an organization is asking to spend money outside either the Annual Plan or Quarterly Forecast, you should develop a business case showcasing what the spend is for and how Gitlab can benefit from spending it.

This business case should be completed in conjunction with your Finance Business Partner (FBP) to articulate the financial impact of the request. Below are a few examples of the question you should be trying to answer:

Together with your FBP , this analysis should be presented to your leader for approval.

Monthly Finance Planning Meeting


Each month after the financials have been published, GitLab reviews department spend data in detail. The goal of this analysis is to compare department budgets with actual results and examine any material discrepancies between budgeted and actual costs. These costs are reviewed at the divisional department level, allowing GitLab to measure progress in meeting its plan, forecast, and operating model. During the meeting, the Finance Business Partners will review GitLab results in addition to a detailed overview. Each division can expect to review the following during the monthly meetings:

  1. Company results
    • Bookings IACV, TCV
    • Spending OpEx vs Plan
  2. Divisional level review
    • Last month and last fiscal quarter (once per quarter)
  3. Department level review
    • Last month and last fiscal quarter (once per quarter)
  4. Review next 4 quarters vs Plan for the Division and for each department


Following the month-end close, the Finance Business Partners will distribute department income statements to the related budget owners and the e-group members. Each department is then responsible for comparing these reports, which contain actual costs, to the budget. Departments, with guidance from the Finance Business Partners, should analyze their data and if necessary, discuss items of interest and take appropriate action. Any questions regarding the cost data should be discussed with the Finance Buisness Partner.


  1. The Accounting Manager will send the income statements on or before the 15th of each month.
  2. The Finance Business Parters will prepare a templated budget vs actual reporting package for distribution to the divisional and departmental leaders.
  3. With guidance from the Finance Business Partners, each division and department leader will review the budget vs actuals in the same month.

Expense Controls and Improving Efficiency

  1. The primary mechanism to ensure efficient spend of company assets is the approval process prior to authorization. See Signature Authorization Matrix.
  2. The second mechanism is the budget vs actual review to determine reasons for variances vs Plan.

Calendar of Events

We follow the cadence below in our planning process:

Throughout the year the Executive Business Partner team puts together a calendar of events for board members and other events associated with planning. Those events can be found in the GitLab Board Calendar sheet.

Monthly Update

Monthly Important Dates

Quarterly Forecast

Quarterly Important Dates

Annual Plan

Annual Planning Important Dates


GitLab Integrated Financial Model

Business Drivers

At GitLab, planning starts with long term goals. GitLab uses business drivers to forecast out long term goals by division. By using division specific business drivers that tie into the long term goals, GitLab is able to quickly and dynamically shift priorities based on external or internal changes.

Business drivers are the key inputs and activities that drive the operational and financial results of a business.[^3]

Long Term Profitability Targets

Our long term profitability target for EBITA (Earnings Before Interest Taxes and Amortization) is 20% of revenue. Our long term gross margin target is 85% but is dependent on the revenue mix between products - self managed and and professional services. Gross margin is defined as total revenue less cost of revenues as defined by GAAP and reported in the Company's financial statements. Other financial planning targets are described in the divisional area (e.g. sales, marketing, development, etc.) in this handbook. We plan to achieve our long term profitability target in FY25-Q4. The long term target for operating expenses as a percentage of revenue for G&A is 10%.

FY20 Financial Planning Goals

Division FY20 Expense Target
Customer Support 10% of ARR
Customer Solutions 80% of PS Recognized Revenue
Engineering 70% of IACV
Sales 75% of IACV
Marketing 45% of IACV
G&A 10% of Total Operating Expense

FP&A Team Responsibilities

Manager, Financial Planning & Analysis

  1. Coordinates Monthly Investor Update
  2. Coordinates Rolling 4 Quarter Process
  3. Coordinates Annual Planning Process
  4. Ensures GitLab's financial model and forecast is accurate
  5. Partners with Business Operations to ensure Financial Systems & Integration Roadmap
  6. Develops data processes in partnership with the Data team
  7. Responsible for financial and mechanical integrity of the operating model and street model

Position Description

Finance Business Partner

  1. Reviews BvsA Analysis with e-group member (or designee)
  2. Responsible for leading the Rolling 4Q forecast process
  3. Building integrated financial model with gearing ratios for business.
  4. Coordinates Monthly KPI and OKR prep
  5. Maintain and develop KPI definitions for divisional business units
  6. Develops and maintains cost and efficiency benchmarking
  7. Develops and maintains Unit economic analysis
  8. Partners with division leaders to ensure financial and key metric forecast accuracy of supported division
  9. Provides Adhoc Analysis to supported division leaders
  10. Helps business group negotiate Vendor Contracts
  11. Develops and maintains compensation modeling

Position Description - Engineering Specific

Position Description - Sales Specific

Financial Analyst

  1. Reviews BvsA Analysis - G&A Division
  2. Partners with Recruiting on hiring plan
  3. Develops and maintains contract & renewal projections
  4. Develops and maintains monthly audit projects
  5. Develops and maintains planned vs actuals GitLab Team analysis
  6. Reviews BambooHR to ensure GitLab Team are in the correct divisions and departments

Position Description

Data Analyst, Finance

  1. Support the FP&A team in driving financial and operational initiatives by analyzing data and discovering insights
  2. Focus on financial and operational specific data
  3. Priorities will be set by the Financial and Operations Lead but will collaborate with and report into the Data Team
  4. Expand our data warehouse with clean data, ready for analysis
  5. Understand and document the full lifecycle of data from numerous sources and how to model it for easy analysis
  6. Build reports and dashboards to help teams identify opportunities and explain trends across data sources
  7. Follow and improve our processes for maintaining high quality data and reporting
  8. Implement the DataOps philosophy in everything you do
  9. Build upon and document our common data framework so that all data can be connected and analyzed

Position Description

Cost Analyst

coming soon…..

Business Analyst, Finance

coming soon…..

Data Scientist

coming in Q1-2020

Department Structure

Creating New Departments

Successfully creating new departments require that various company systems be updated to capture newly defined department structures. Once the need for a new department arises, follow these steps:

  1. Create an issue using the dept_change template.
  2. In the issue, add the appropriate team members from each department included in the checklist.
  3. Disclose the nature of the new department. Is the new department simply a name change, or there is a structural modification?
  4. Provide all detail necessary to ensure team members are assigned to the newly created departments.

Below is a table showing the structure of GitLab departments as they exist in BambooHR and netsuite. Please check out the Team Page to see our org chart.

By Division - Where GitLab team-members Report

Sales Marketing Engineering Product G&A Meltano
Alliances Corporate Marketing Infrastructure Product Management Business Operations Meltano
Channel Demand Generation Development   CEO  
Commercial Sales Digitial Marketing Quality   Finance  
Customer Solutions Field Marketing Security   People  
Customer Success Marketing Ops UX   Recruiting  
Enterprise Sales Product Marketing Customer Support      
Field Operations Community Relations        

Allocation Methodology

GitLab allocates cost items based on consumption of resources or headcount. Below are the workflow and diagrams that illustrate how various cost items are allocated:


Pre-Allocation P&Ls

The grid highlighted as Pre-Allocation P&Ls in the diagram below highlights what GitLab P&L structure would look like if there were no allocation methodology. The grid represents Cost Centers and Departments that fall within those Cost Centers. In order to support different dimensional P&Ls and ensure expenses are flowing to the proper Cost Center, GitLab applies an allocation methodology. Therefore, the Pre-Allocation P&Ls is meant to provide clarity and be a starting point to the allocation methodology process.

Allocation Methodology

The grid highlighted as Allocation Methodology in the diagram below highlights the specifc processes that occur in order to achieve proper expense allocations to their respective Cost Centers.

Step 1: Yellow Process

The allocation methodology is applied to the G&A Company Allocation department, Business Operations Program Spend, and the Recruiting department. Only items that are used by the entire company are captured in Business Operations Program spend (examples include gmail and slack). In addition to Business Operations Program Spend and Recruiting expenses, there are times GitLab needs a catch all account for one off expenses (examples Contribute, payroll service fees, etc). Those expenses are allocated in the same fashion as Business Operations Program Spend and Recruiting, but those expenses are recorded to the G&A Company Allocation department, before allocation.

  1. Business Operations Program Expenses. All 6060 Spend
  2. Recruiting Department
  3. G&A Company Allocation department for all one off expenses.

Note: One thing to note during the Yellow Process is the Infrastructure expenses are removed. Infrastructure is allocated during the next phase of the allocation cycle. Therefore no shared expenses will hit the Infrastructure P&L.

Step 2: Red Process

The allocation cycle for GitLab's SaaS offering starts. The Finance Business Parter for R&D maintains an allocation model to provide Accounting with an allocation breakout of expenses as well as a P&L based on allocation. The model can be found by searching My Drive > Model. The allocation for is broken out into two different methods.

  1. Free vs Paid Users
    • Infrastructure
    • 3rd Party Expenses [i.e. Hosting Services]
  2. Percentage of Revenue
    • Customer Support

These allocation breakouts will be documented in the model and will flow into the Post Allocation P&Ls. GitLab allocates these expenses to 3 Cost Centers

  1. Marketing - Free users
  2. R&D - Internal users
  3. Cost of Sales - Paid users
Step 3: Blue Process

The Blue Process, which encapsulates the Yellow and Red process, is meant to bring the full allocation cycle together before the Post Allocation P&Ls are rendered.

Post Allocation P&Ls

The grid highlighted as Pre-Allocation P&Ls in the diagram below highlights the final process during the allocation cycle. As a result, new P&Ls are generated to show the breakout of the Infrastructure team across Cost Centers as well as


alt text


Creating & Updating Models

If you create and/or update to a model that materially impacts it, please make sure to make a quick note of what you did in the ChangeLog. This is important because it keeps us on all the same page.

Note: At this time, GitLab use's the term Division to describe the makeup of its internal structure. In the future, the plan is to use the term Function to describe it's internal structure.