This page contains GitLab's accounting and reporting policies, desktop procedures and guidelines. Our goal is to complete the monthly accounting close process within 10 business days from the last day of the month. Accounting and reporting process at GitLab is classified as enumerated below.
Quote to Cash is a set of business processes from receiving and fulfilling customer requests for products or services to collecting cash. Below is the list of applications used in this process.
|Applications||Purpose of the application|
|Sales force||Application used for generating leads, updating opportunities and generating quotes|
|Data fox||Tool used for obtaining lead details|
|Zuora||Application used for managing price masters, invoicing to customers and updating collections from customers|
|Shopify||Application used for sale of GitLab merchandise to customers|
|Net Suite||ERP system used to record the financial transactions|
Below are the sub processes in Quote to Cash Process
** Calculated Billings** Calculated billings is defined as revenue plus the sequential change in total deferred revenue as presented on the balance sheet.
We do not believe that calculated billings provides a meaningful indicator of financial performance as billings can be impacted by timing volatility of renewals, co-terming upgrades and multi year prepayment of subscriptions.
For order approval and invoicing process please view the Billing Ops page.
Invoicing: One Time Events
To amend a customer's account, choose one of the options below from the subscription page in Zuora.
Zuora Subscription Data Management
New Accounts vs New Subscriptions
There are instances where a new account in Zuora is required rather than just a new subscription in an existing account. This is determined by the sold-to contact person.
Within the customer account portal, customers can only see a single Zuora account at a time. If a customer wants to add a subscription and the contact information is the same, then the subscription can be added to the existing account.
If a customer wants an additional subscription for a different sold to contact, then a new Zuora account will be created so that every sold to contact can log into the portal and manage their subscriptions.
Linking Renewal Subscriptions
When a customer renews their subscription, a new subscription is typically created. This can create challenges for calculating metrics like dollar retention for a subscription because once subscription has ended and another has started. To address this, a linkage is made between the original subscription and its renewal(s).
Renewal subscription is used to create the mapping. These are the following constraints on this field:
A-S00009096 || A-S00009095
The process to make the linkage is as follows:
The active subscription status in Zuora needs to be reviewed in connection to the end date. If the end date is in the future it means that the subscription is still within the term and the customer is able to use the product. An ‘active’ subscription with an end date in the past means that the subscription was not renewed and the customer doesn’t have access to the product since the end date. We currently don’t actively cancel these subscriptions as this is a manual process and the cancellation or lack of it does not have any impact on other processes. Additionally, where subscriptions remain in an active status they can be renewed by the customers on the customer portal
For step by step processes please view Billing Ops page.
How to process a partial refund in Stripe
Posting Swag Shop transactions in NetSuite Transactions from the Swag Shop are remitted to the Comerica checking account daily and should be booked in NetSuite at the end of each month.
Credit card customer
Follow this procedure if the customer paid by credit card. You may recall from the invoicing process that there was still a balance due when saving the invoice. The following steps will record the payment and remove the balance due.
This transaction transfers the payment obligation from the customer to Stripe. The payment obligation from Stripe is removed when Stripe transfers the funds to GitLab's bank account.
Posting a payment from Stripe when a transfer is received from Stripe
Post a journal entry:
Posting a payment from a “bank customer”
For step by step cash collections process please view Billing Ops page.
Account receivable provisions, bad debts and other period close adjustments
Time for Invoices to be generated when a deal is closed won in Salesforce < 24 hours
The time from when a deal is closed won in Salesforce to when the invoice is generated. Professional services are excluded from this performance indicator. This is tracked over a calendar month. The target is < 24 hours.
Procure to pay is the process of requisitioning, purchasing, receiving, paying for and accounting for goods and services. It includes the following sub processes
Please note Tipalti go live is 2019-11-01; therefore, any already existing active vendors will be sent a one-time onboarding request from Tipalti via email. Vendors need to onboarded themselves into Tipalti in order to be paid. If you are a GitLab recurring vendor and did not get an onboarding email from Tipalti please reach out to email@example.com.
Invoices will arrive by email to firstname.lastname@example.org or directly uploaded into the Tipalti Portal by the vendor.
Entering a Bill (invoice) in NetSuite Please note the below steps reference how to manually enter bills into NetSuite. Effective 2019-11-01 all AP invoices should be getting processed through Tipalti and will automatically record the transaction into NetSuite after the invoice has been approved by the corresponding business partner.
Processing payment for invoices
Please note: Invoices will be paid upon vendor payment terms. Any invoice approved and sent to AP by EOD Tuesday can be paid the same week on Friday and/or based on the vendor payment terms if the terms are NOT due UPON Receipt. Any invoice approved and sent to AP from Wednesday to Friday of that week will be paid the following Friday and/or based on the vendor payment terms, whichever comes first.
Processing Expensify Reports
Paying Expensify Reports
Tipalti Paid Reports paid through GitLab's AP Department:
Please Note: The timing of reimbursement can vary if you are being reimbursed directly from payroll, CXC, SafeGuard and/or iiPay
Expense Specialist Job Family Performance Indicators
Average days to action <= 3 business days
Number of days from when an employee's manager approves report to when expense specialist does final approval for payment or responds to employee in Expensify if there is a concern. (Approval for payment is not the reimbursement date.) This is calculated on a calendar month basis. The target for this is currently three business days.
Time to get a new employee set up in Expensify < 3 business days
Have new employee set up in Expensify within 3 business days from employee start date.
Travel and Expense Guidelines
When reducing spend, we'll not take the easy route of (temporarily) reducing discretionary spending. Discretionary spending includes expenses like travel, conferences, gifts, bonuses, merit pay increases and summits. By reducing in these areas we put ourselves at risk of increasing voluntary turnover among the people we need most. Discretionary spending is always subject to questioning, we are frugal and all spending needs to contribute to our goals. But we should not make cuts in reaction to the need to reduce spend; that would create a mediocre company with mediocre team members. Instead, we should do the hard work of identifying positions and costs that are not contributing to our goals. Even if this causes a bit more disruption in the short term, it will help us ensure we stay a great place to work for the people who are here.
Renting Cars in the United States and Canada
Third Party Liability
Purchase the liability insurance that is excess of the standard inclusion of State minimum coverage in the rental agreement at the rental agency. GitLab’s insurance policy provides liability insurance for rental cars while conducting company business, but it may be excess over any underlying liability coverage through the driver or credit card company used to purchase the rental.
Purchase the liability offered at the rental counter if there are foreign employees renting autos in the US or Canada. While workers' compensation would protect an injured US employee, other passengers may have the right to sue. To ensure that GitLab has protection when a foreign employee invites another person into the car we recommend the purchase of this insurance when offered at the rental counter.
Physical Damage – Collision Damage Waiver
Do not purchase the Collision Damage Waiver offered at the rental counter. GitLab purchases coverage for damage to rented vehicles. If travel to Mexico is required, purchase the liability insurance for Mexico offered at the rental counter. You should verify that the rental agreement clearly states that the vehicle may be driven into Mexico and liability coverage will apply.
Renting Cars- Countries other than the US and Canada
Third Party Liability
Purchase the liability insurance offered at the rental counter when traveling outside the US and Canada. Automobile Bodily Injury and Property Damage Liability insurance are required by law in almost every country. Please verify this coverage is included with the rental agreement.
Physical Damage – Collision Damage Waiver
Purchase the Collision Damage Waiver or Physical Damage Coverage offered by the rental agency when traveling outside the US and Canada.
In the event of an accident resulting in damage to the rental car, the foreign rental agency will charge the credit card used to make the reservation with an estimated amount of repair costs if insurance is not purchased. If this happens, GitLab does not purchase Foreign Corporate Hired Auto Physical Damage Coverage to reimburse for damages.
Personal Use by Employee or Family Members of Business Auto Rentals
Coverage is not provided for personal use of automobiles or when family members are driving. Please evaluate whether your own personal automobile insurance provides an extension for this coverage. If it does not, or you are renting a vehicle outside the US or Canada or taking a US rented vehicle into Mexico, we recommend that you purchase the liability and physical damage coverage offered by the rental agency to protect your personal liability when not engaged in company business. GitLab will not pay for liability or damage to the rental vehicle resulting from personal use or use by non-employees.
In order to purchase goods and services on behalf of the company, you should first consult the Signature Authorization Matrix to determine the approval requirements. Note that this does not include travel expenses and other incidentals. These expenses should be self-funded then submitted for reimbursement within Expensify, or in the case of independent contractors, included in invoices to the company (per the guidelines above).
If approval is not required, then proceed and send the invoice to Accounts Payable (email@example.com). If approval is required, create a confidential issue in the Finance Issue Tracker and tag the required functional and financial approvers. Most importantly, the team member making the purchase request is ultimately responsible for final review and approval of the invoices. Final review and approval are critical process controls that help ensure we don't make erroneous payments to vendors. All original invoices and payment receipts must be sent to Accounts Payable.
Creation of Expense Tags
In NetSuite: If you would like to track spend for a particular campaign, project and/or event you can do that through expense tag also known as classes in NetSuite. If you would like to request an expense tag to be set up please send your request to firstname.lastname@example.org and they can set it up for you.
Expensify will auto-sync any new "expense tags" on a daily basis but if the Expensify admin wants to manually sync they can by following these steps:
We have worked to reduce the number of outstanding company credit cards in an effort to centralize corporate purchasing, however, there are still certain situations where it may be more practical to issue additional corporate cards. This will be addressed on a case-by-case basis and final approval will come from the CFO. Please contact the Finance team if you would like further information on this.
GitLab team-members carrying company cards in their name are required to submit expenses in Expensify on a monthly basis. Reports are to be submitted no later than the fourth business day of each month as the American Express statement period-end date is generally between the 28th and 30th of each month.
Card transactions are auto-imported into Expensify which then auto-generates the expense reports to match that of the American Express statements. Below you will find directions on how to sign up for an American Express account and submit these expenses in accordance with company policy.
Creating an American Express account
Once you receive your card, register the card in the American Express portal.
Submitting company credit card expenses
On a daily basis, Expensify will auto-generate an expense report and leave the report open until it is submitted. You can submit your report(s) on a regular basis but need to ensure that all are submitted no later than the 3rd business day following the statement end date. Please help to ensure you are submitting all expenses which corresponds to the American Express statement period. Accounting will send out a reminder email informing you of the statement period and due date of when the report(s) need to be submitted by. Before submitting any expense report you must ensure the following:
1. Coding expenses
2. Required supplementary information Certain purchases require additional data in order for the Finance team to accurately process transactions.
Expense reports are considered incomplete if missing any of the following data:
3. Attaching receipts
4. Submit the report
Note that company credit card expenses should never be commingled with reimbursable expense reports. Reimbursable expenses should always be submitted separately. Please contact the Accounting Manager if you have any questions.
Marketing Campaign Expenses Please see the campaign expense guidelines in the Marketing handbook. GitLab Contribute Cost Tracking (Previously GitLab Summit) Tracking expenses for company Contributes enables us to analyze our spend and find opportunities to iterate, and in turn, improve subsequent Contributes. To enable tracking we create an expense tag that will allow GitLab team-members to tag Contribute related expenses in Expensify. This should be done prior to the announcement of each Contribute.
Property, plant and equipment is the long-term asset or noncurrent asset section of the balance sheet. Following are the sub-processes:
Capital Assets Policy
Purpose This policy establishes the minimum cost (capitalization amount) used to determine the capital assets recorded in GitLab's financial statements.
Capital Assets Defined
A “Capital Asset” is a unit of property that has an economic useful life extending beyond 12 months and was acquired (or in some cases, produced) for a cost of $5,000 (USD) or more. Capital Assets must be capitalized and depreciated for financial reporting purposes.
GitLab establishes $5,000 (USD) as the minimum amount required for capitalization. Any item with a cost below this amount is expensed on the date of purchase.
All capital assets are recorded at historical cost as of the acquisition date. These assets are depreciated on a straight-line basis, with the number of depreciation periods being determined by asset class.
Equipment: For our purposes, equipment generally consists of computers and other related office tools. Equipment under our INC entity is assigned a standard useful life of three (3) years. However, equipment under our BV entity is depreciated over five (5) years due to Dutch tax laws, which limit depreciation of capitals assets to a maximum of 20% of the asset cost per year. The following link contains additional information on Dutch tax laws surrounding capital and fixed assets: Netherlands Capital and Fixed Assets Guide
Furniture: Furniture includes office furniture and other fixtures. The standard useful life for furniture is seven (7) years. This depreciation schedule applies to all entities.
Invoices and purchase receipts for capital assets are retained for a minimum of five years.
Items paid for by the company are property of the company. Assets with purchasing value in excess of $5000 USD are recorded through NetSuite and tracked using BlackLine with an account reconciliation which includes details by individual asset purchased. The account reconciliation serves as an asset register. The accounting team we capture by individual asset purchased the following information:
Once the information is captured in BlackLine a depreciation schedule will populate and accounting will book an entry in NetSuite each month to record the depreciation of the asset until it is fully depreciated.
Assets will be disposed of if purchased by an employee upon termination (if approved by ITOps) or if the item is no longer useful before the useful life.
If a team member would like to purchase an asset from the company (i.e. a laptop), they would request through an issue to IT Ops and accounting to obtain the amount to be paid. This is derived from original cost less accumulated depreciation. If and asset is purchased accounting team will collect the funds and will book the appropriate accounting treatment to dispose of the asset.
If an asset is no longer usable before the useful life has been reached the employee needs to submit an issue to IT Ops and accounting to inform them. IT Ops will evaluate and if they deem the item is no longer useful accounting will book the appropriate accounting treatment to dispose of the asset.
Record to report is a Finance and Accounting process which involves recording financial transactions that will provide stakeholders with financial information to understand how the business is performing.
Below is the list of applications used in this process.
|Application||Purpose of the application|
|Net Suite||ERP system used by the Finance team to record the financial activity|
|Blackline||Application used to automate and standardize reconciliation process|
|Carta||Stock option administration, capitalization table and equity management software platform|
|Zuora||Application used for invoicing to customers|
Record to report process is governed by the following accounting policies:
Purpose This policy defines related-party transactions, identifies the significance of related party accounting implications and provides guidance regarding approval and reporting of related-party transactions in relation to GitLab.
Scope This procedure applies to the Key Management Personnel (members of the e-group), Board of Directors and their relevant entities/VC’s they represent and to all the related party transactions. Finance and Legal will jointly review all reported potential related party transactions.
Policy All transactions with related parties require the prior approval of the Chief Financial Officer. In the event the related party transaction involves the Chief Financial Officer the Chief Legal Officer will be responsible for approving. In considering the approval of a related-party transaction, a legitimate business case must be developed including the arm's length nature of the proposed transaction and the disclosure implications of such a transaction in GitLab's financial statements. Applicable standard or Regulation Securities and Exchange Commission Regulation S-K (Item 404 (b); FASB statement no 57. Definitions: Related party transactions: A business deal or arrangement between two parties who have an existing relationship (i.e a purchasing agent buying materials from a company owned by a spouse).Transactions that exceed $120,000 per year concerning executives, directors and stakeholders with 5% or more of company stock (or an immediate family member) legally requires disclosure to the SEC for publicly traded companies per Security and Exchange Commission Regulation S-K Item 404 (b). Related Party: The Financial Accounting Standards Board defines a related party in Statement No. 57 (FASB 57), Related Party Disclosures. For the purposes of this policy, a related party is:
Procedures Accounting Implications The existence of related-party transactions may have a significant effect on GitLab’s financial statements. Transactions between or among related parties differ from transactions between unrelated parties in that they are, by definition, not at arm's length. Not dealing at arm's length may significantly influence the price and terms of transactions, and make it difficult to distinguish between the form and the substance of the transaction. Except for recurring transactions, the assumption is that it is difficult to substantiate that a related-party transaction is at arm's length as it is generally not possible to determine whether such a transaction would have taken place or what the terms and manner of the settlement would have been had the parties not been related. FASB Statement No. 57 requires GitLab to disclose significant related party relationships and transactions in GitLab's financial statements. This disclosure is considered significant because it provides the user of the financial statements with relevant information to interpret GitLab's operating results. Legal and Finance will send to the relevant parties (Board Members, Key Personnel) quarterly and/or yearly a form to detail potential related party transactions or to confirm those that were reviewed prior of potential related party transactions. These will be reviewed and reported in GitLab’s financial statements as outlined above. Reporting of related party transactions In the event that a related-party transaction is contemplated, the transaction should immediately be discussed with GitLab's chief financial officer or Principal Accounting Officer. Details of the proposed transaction to be discussed include:
Purpose The purpose of this policy is to establish the responsibility, authority and guidelines for the investment of operating surplus cash. Surplus cash is defined as those funds exceeding the operating requirements of the Company and not immediately required for working capital or near term financial obligations.
Scope This policy shall apply to the Company and all subsidiaries. This investment policy will be reviewed periodically to ensure that it remains consistent with the overall objectives of the Company and with current financial trends.
Approved Brokerage Institutions The Company may use the following brokerage institutions:
The basic objectives of the Company’s investment program are, in order of priority: Safety and preservation of principal by investing in a high quality, diversified portfolio of securities, mutual funds, and bank deposits. Liquidity of investments that is sufficient to meet the Company’s projected cash flow requirements and strategic needs. Maximize after-tax market rates of return on invested funds that are consistent with the stated objectives herein, conservative risk tolerance and the Company’s current tax position. Maturity Limits Individual security maturities should not exceed 24 months. The weighted average maturity of the portfolio shall not exceed 12 months. A maturity or effective maturity by definition shall include puts, announced calls or other structural features which will allow the Company to redeem the investments at a quantifiable price consistent with liquidity, safety and preservation of capital.
Eligible Investments United States Government Securities: Marketable debt securities which are direct obligations of the U.S.A., issued by or guaranteed as to principal and interest by the U.S. Government and supported by the full faith and credit of the United States. United States Government Agency Securities: Debt securities issued by the Government Sponsored Enterprises, Federal Agencies and certain international institutions which are not direct obligations of the United States, but involve Government sponsorship and are fully guaranteed by government agencies or enterprises, including but not limited to: · Federal Farm Credit Bank (FFCB) · Federal Home Loan Bank (FHLB) · Federal Home Loan Mortgage Corporation (FHLMC) · Federal National Mortgage Association (FNMA)
Money Market funds
Money Market Funds must be rated AAA or equivalent by at least one NRSROs.
At time of purchase investment restrictions:
Investment Products (Rating, Sector Concentration, Issuer Concentration)
Purpose This policy describes the methodology used to monitor and account for GitLab’s prepaid expenses.
Prepaid Expenses Defined A Prepaid Expense arises when a cash disbursement is made for goods and services prior to realizing the associated benefits of the underlying goods and services. These transactions are recorded as assets until the goods and services are realized, at which point an expense is recorded. Our minimum threshold for recording prepaid expenses is $10,000 USD. Anything under this amount is expensed immediately.
Identification and Recording of Prepaid Expenses Once a purchase request makes it through the company approval workflow, Finance will take the following steps to ensure prepaid expenses are recorded accurately:
The Accounts Payable Administrator flags all bills that qualify as prepaid expenses during the normal course of processing bills in the AP mailbox.
The flagged bills are then analyzed and added to the asset register located in Google drive. Information includes expense category, department, benefit period, and amount to be amortized.
At the end of each month, the Accountant reconciles the prepaid additions to the general ledger, which includes verifying amortization schedules and amounts.
Amortization is recorded straight line based on a mid-month amortization method as follows: If the first month of service begins on the 1st to the 15th of the month, a full month amortization will be recorded in the current month. If the first month of service begins on the 16th to the last day of the month, amortization will begin on the 1st day of the subsequent month.
Mid-Month Amortization Method does not apply to prepaid expenses with a monthly amortization equal to or greater than 50,000 USD or if the amortization if spread only over 1 period. If monthly amortization is equal to or more than 50,000 USD, the first month amortization will be calculated based on actual number of days where services were rendered.
Prepaid Not Paid: For any prepaid expenses not processed for payment, an adjustment for "prepaid not paid" is posted to the respective prepaid expense account and AP manual adjusment account (GL Account 2001). A prepaid expense is not treated as an asset if a liability remains in the AP sub-ledger. Prepaid not paid adjusments are performed on a quartly basis at minimum. Any deposits paid which will be held for more than 12 months such as security deposits or deposits to retain consultants will be booked to Security & Other Deposits (GL Account 1620)
Prepaid Bonuses with a Clawback will be recoreded to Prepaid Bonus w/Clawback (GL Account 1152) and will be amortized in accordance with the bonus agreement terms, using the mid-month convention.
Contribute related expenses Team member travel expenses are expensed in the period incurred. Costs related to third party vendors such as hotels, facilities, excursions are recorded to prepaid expenses and recognized as expense at the time of the event.
Purpose To provide clear guidance concerning the identification and recording of items included in GitLab’s accrued and other liability accounts. The purpose of monthly accrual processes is to allocate expenses to the proper accounting period and match expenses with related revenues. At the close of each month, accrual processes ensure that all expenses related to that month are correctly included in the company's financial statements. Additionally, this policy establishes standards and guidelines for ensuring that GitLab accounts for monthly accruals in a manner that is compliant with management's objectives and generally accepted accounting principles (GAAP). This policy applies to GitLab and all subsidiaries.
Identification We require that all expenses be recorded where expense exceeds $5K USD or above, in the period the expense was incurred. The accrual process should be completed on a monthly/quarterly basis to ensure liabilities are recorded accurately in their respective periods and/or quarters. Accruals are booked by vendor, invoice and/or approved finance contract issue. If multiple invoices are less than $5K USD for the same vendor in the same period and the aggregate exceeds $5K USD the expense maybe considered for accrual on a quarterly basis.
The following items should be accrued monthly as necessary (note: this list is not all-inclusive):
Obligations that accrue over time are recorded throughout the accounting period in a methodical and rational manner. Obligations that accrue when an event occurs should be recorded at the time of the event.
Factors that are considered in determining the time of recording accrued liabilities include:
Procedural The Finance team is responsible for having procedures in place to reconcile accounts monthly and for keeping documentation to support accrued liabilities. Payables and accrued liabilities are recorded at face value, plus or minus any applicable adjustments. In most cases, the payable amount can be determined from the vendor bill. If not, then the amount should be verified against any relevant documents before recording the liability. When actual values are not available, the recorded value should be based on best available estimates. Estimates should be based on current market price and experience/history.
The Sr. Accounting Manager is responsible for performing an overall review of accrued liabilities, one to three business days after accounts payable closes each month, to help ensure that all expenses are captured accurately.
Please see Procure-to-Pay
Purpose This policy establishes the appropriate business use, responsibilities, and authorization of the Company’s credit card policy. The purpose of this policy is to ensure that Company credit cards are used for appropriate business purposes and that adequate controls are established for day-to-day use.
Scope The Company credit card policy applies to all employees who are approved to use a company credit card, including their managers. This policy defines Company credit card access and use, and expense authorization and reimbursement for company employees. This policy applies to all Company locations and departments.
Overview Foreign currency translation describes the method used in converting a foreign entity's functional currency (as determined and documented in GitLab.com>Finance>Issues>#630) to the reporting entity's financial statement currency. Prior to translating the foreign entity’s financial statements into the reporting entity’s currency, the foreign entity’s financials must be prepared in accordance with generally accepted accounting principles (GAAP), specifically under Financial Accounting Standards Board (FASB) Statement No.52. GitLab’s financial statement reporting currency is USD. The functional currency of our non-U.S. subsidiaries is the local currency. Changes in foreign currency translation are recorded in other comprehensive income (loss), which is reported in the consolidated statement of equity and ultimately carried over to the consolidated balance sheet, under equity.
Exchange Rates Exchange rates used in the currency translation process vary across the three primary financial statement components:
Transaction Risk vs Translation Risk
Currency Transaction Risk Currency transaction risk is due to company transactions denominated in foreign currencies. These transactions must be restated into the entity functional currency equivalents before they can be recorded. Gains(losses) are recognized when a payment is made or interim balance sheet dates.
Currency Translation Risk Currency translation risk occurs due to the company owning assets and liabilities denominated in a foreign currency.
Cumulative Translation Adjustment A cumulative translation adjustment (CTA) is an entry to the comprehensive income section of a translated balance sheet that summarizes the gains(losses) resulting from exchange rate differences over time. Currency values shift constantly, affecting how a currency is valued against others. The CTA is a line item in the consolidated balance sheet that captures gains(losses) associated with international business activity and exposure to foreign markets. The changes in CTA are recorded in other comprehensive income (loss). CTA’s are required under GAAP since they help distinguish between actual operating gains(losses) and those that arise from the currency translation process. Additional information on our reporting standards surrounding CTA's can be found in FASB Topic 830, "Foreign Currency Matters."
Recording CTA - Exchange rate gains and losses for individual transactions are captured automatically by our ERP system, NetSuite. However, a CTA entry must be made in order to properly distinguish currency translation gains(losses) from other general gains(losses) in the consolidated financial statements. This entry includes reconciliation of any intercompany activity that generates foreign exchange gains(losses). The CTA is made on a monthly basis as part of our financial statement reporting cycle.
Scope This policy establishes GitLab’s guidelines regarding the structure, responsibilities and requirements underlying the chart of accounts (COA).
Purpose This policy establishes formal responsibilities and accountabilities for how GitLab handles requests for new, modified or closed data elements on the COA. The Controller is responsible for all aspects of financial accounting and reporting, and governs the COA. All requests for new or modified (including closure/deactivation) COA segments, hierarchies, and configuration attributes are subject to approval by the Finance team.
Changes to the COA All requests for new or modified accounts must be submitted to the Accounting Manager for review and approval through a request using the Finance issue tracker.
There are other stakeholders associated with the COA that may influence certain business decisions or financial system configurations. The Controller and Accounting Manager will include selected stakeholders in the related procedures and processes when and if appropriate. Potential stakeholders include, but may not be limited to:
The general ledger attributes subject to this policy will be defined by the Controller based upon factors including but not limited to:
Once an amendment to the COA has been approved, the Accounting Manager will ensure the necessary changes are implemented by updating and then closing the issue.
Administration The COA is maintained in NetSuite. Changes to the COA can only be made by the Controller and/or Accounting Manager.
Scope This policy applies to GitLab Inc. (“GitLab” or the “Company”) and all of its subsidiaries.
Purpose To establish guidelines for assessing, preparing and reviewing balance sheet account reconciliations on a consistent basis in accordance with corporate policies and US Generally Accepted Accounting Principles (“GAAP”).
Policy Account reconciliations are prepared and reviewed monthly or quarterly for each active balance sheet account at the natural account level based upon the risk rating assessed (see risk rating assessment below). Account reconciliations will be prepared consolidated in USD or by entity in the respective functional currency.
Each month end close the Senior Accounting Manager assigns each balance sheet account or groups of accounts to its respective preparer and reviewer using BlackLine (Account Reconciliation Tool). The assignments are set once and will roll over into the next accounting period. The Senior Accounting Manager will make changes to assignments as needed. The preparer and reviewers can not be the same person to ensure segregation of duties.
The balances from NetSuite will be auto synced into BlackLine each period end so the preparers can prepare their recons based on the NetSuite ending balance for their respective assigned accounts.
The preparer(s) will ensure the following:
The reviewer(s) will ensure the following:
BlackLine will auto certify the recon on our behalf if the following is met:
If the balance changes after review, approval or auto certification the recon will automatically be decertified by BlackLine and the preparer and reviewers will need to follow the above steps again.
Risk Rating Assessment Once a year in the beginning of Q4, the Controller and/or CFO will review each active balance sheet account and rate it from High, Medium and Low. The risk level of each account is evaluated based both on the quantitative value (to determine materiality) and the qualitative factors listed below:
High Risk Accounts will be reconciled by the preparer monthly (for the exception of tax and equity related accounts which will be reconciled quarterly) and will require 1st level review by an accounting manager or above and 2nd level review by the CFO or PAO.
Medium Risk Accounts will be reconciled by the preparer monthly and will require 1st level review by an accounting manager or above.
Low Risk Accounts will be reconciled by the preparer monthly or quarterly and will require 1st level review by an accounting manager or above.
If there is no activity and/or the account balance is zero the reconciliation will be auto certified by BlackLine.
Once each reconciliation is reviewed/approved the account reconciliation is locked in BlackLine and no further changes can be made for that period.
Completeness Check Once the period is officially closed the Senior Accounting Manager will ensure all recons are in approved, reviewed or in a auto-certified status before moving into the next period.
The process of allocating and recomputing the recognizable revenue when the contractually stated price for any deliverable is not proportionate to the corresponding “fair value” (stand-alone selling price of each deliverable). Therefore, GitLab has created the process below to help recognize revenue accordingly.
The process for this is listed below:
The below details the current reporting structure for GitLab. This will be updated as our reporting evolves.
Defined as cash in the bank. Also counts short term securities that are readily convertable into cash within the next 90 days.
The change in cash balance from period to period excluding equity or debt financing. Average cash burn is measured over the prior three months. The analysis can be found on the Finance Dashboard. Cash data is sourced from Netsuite.
The amount of contractually committee line of credit extended by the bank that is not in default status.
Cash flow from operations as defined by GAAP less Capital Expenditures.
Total operating expenses plus capital expenditures.
The amount of subscription revenue recognized using ratable accounting treatment as calculated by the subscription amount divided equally over the subscription term. Note that other GAAP adjustments such as non-delivery, performance obligations are not accounted for in this metric.
GitLab has an established GL Accounting system for reporting specific expenses. However, sometimes additional GL accounts need to be added to better clarify expenses that occur as GitLab continues to mature as an organization. When the need for a new GL account arises, Accounting will create an issue in the Finance repository and notify the following teams to ensure the changes are effectively communicated.
(Open, closing of bank accounts, approvals, authorization matrix etc) Desktop procedures
All deals with a contract value above $50,000 executed in a particular week to be reviewed for revenue recognition matters, before the end of Wednesday of the following week.
An issue to be opened for all key technical accounting matters within 2 working days of obtaining knowledge about the same.
All key technical accounting matters to documented in an accounting memo within 5 working days of opening an issue thereon.
All routine technical accounting queries to be disposed of within 2 working days.
The accounting team uses standard and advanced intercompany journal entries to complete their monthly close processes. In addition, mass loads are used to add or update vendor and employee records, for example. See link for templates. JE and Mass Load templates
Journal entries are either manual or system generated. System generated entries would include elimination entries calculated by NetSuite when the elimination process is run as part of month end close or exchange rate adjustments based on final exchange rates. Manual journal entries are entered by the appropriate person in the Accounting department, depending on the nature of the entry. All manual journal entries require approval and posting by a second person in order to verify accuracy and that the appropriate documentation is included with the entry.
Manual journal entries are recorded in order to ensure our financial statements are materially accurate. As such, certain manual journal entries will not be recorded if they are immaterial, as it is inefficient and unnecessary to record entries that would not have a material impact on the users of our financial statements, unless these entries would be material if accumulated. Effective February 1, 2020, thresholds for manual journal entries are as follows:
|Journal Entry Type||Threshold|
|Allocations between Departments (requires approval by FP&A team)||$25,000|
|Prepaids||Expensed in full in the month incurred if less than $10,000|
|Reclass between Accounts||$10,000|
Journal entry types not included above will always be recorded, no matter the amount. These include entries such as bank account activity, payroll, and taxes.
Employee stock options are recorded on a calendar quarterly basis. The puropse of this entry is to record the expense and allocate it between the appropriate departments.
Each month the Senior Accounting Manager will lead a Month-End review to discuss any updates that need to occur before Month-End Close. The review will also include topics for future improvements and to discuss any outstanding tasks from the previous Month-End review. This review is to encourage colloabration, identify efficiences, and quickly fix any discrepancies. The Month-End review guidelines are highlighted below:
In addition to the Month-End review process, Accounting will coordinated the Month-End Close Checklist to ensure all closing tasks are completed.
The number of business days required to report final monthly financial results. As a private company our target is 10 business days moving to 5 business days as a public company. This analysis can be found on the Finance Dashboard. The days to close is sourced from the accounting close checklist.
The monthly close process includes both a preliminary and final close process. If any adjustments come out of the preliminary financial review the Accounting team will book the adjustments before the final financial results are published. After any adjustments are made the accounting team will then record the intercompany calculations and ensure all intercompany eliminates properly before officially closing the month. Once the period is officially closed the accounting team will run the final financials and distribute to the appropriate management team. The intercompany calculations are the very last entry during the month end close process. Therefore, the Accounting team ensures that the preliminary financial results are corrected and/or updated before the intercompany calculations are completed and books are officially closed to improve efficiency.
Each calendar month the intercompany transactions between GitLab entities are settled in accordance with GitLab's Transfer Pricing Concept.
Hire to Retire is the process covering employee recruitment, payroll processing and exit management. Below are the sub-processes: