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.
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
Basic Assumptions
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).
The field Renewal subscription is used to create the mapping. These are the following constraints on this field:
A-S00009096 || A-S00009095The 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 CustomersDot
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.
Accounting for customer collections Cash Receipt
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”
In Netsuite:
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 of both the Procurement and Accounts Payable departments:
Coupa is a procure-to-pay system that streamlines the purchase request process, initiate workflow with approvals, and enable Purchase Orders. We will be rolling out in a phased approach, with the US and Netherlands entities (GitLab Inc, Federal, IT BV and BV) in Phase I (2021-06-01). The remaining entities will be part of Phase II (2021-12-13).
You can learn more about Coupa on our FAQ Page
How vendors are added into Coupa:
If you are a GitLab recurring vendor and did not receive an onboarding email from Coupa, please reach out to ap@gitlab.com.
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 were processed through Tipalti. Effective 2021-06-01 (Coupa Phase I) and 2021-12-13 (Coupa Phase II), AP invoices will be processed in Coupa. These systems will automatically record the transaction into NetSuite after the invoice has been approved by the corresponding business partner in the respective system.
Coupa is a Procurement and Invoicing Tool. Similarly to purchase requests for goods/services that must be initiated in Coupa, invoices are also created and approved in Coupa.
For all issues created before Coupa Go-Live (Phase I; 2021-06-01 and Phase II; 2021-12-13), the business will not be setting up Purchase Orders for those and the Accounts Payable team will manually enter the related invoices as Non PO-backed.
Invoices in Coupa can be created via 4 different channels:
A NetSuite error log identifying invoice integration issues will be emailed to the Accounts Payable Team every Tuesday and Friday. The email is sent from Finance Systems Admins and the Subject is Coupa2NS Invoices - Integration Log. Download the attached file and filter by Type = Error and Audit. Review the Details field to find the invoice number/document number that needs to be reviewed/corrected. For information regarding common errors and how to correct them, please review this file; under the column labeled Script search for Coupa Invoice Integration. If any troubleshooting assistance is needed, please ask in the #coupa_help Slack channel.
There is also a View in Coupa that will list invoices not exported to NetSuite. Under Invoices, select View = Not Exported
However, there will be no details regarding the integration issue. You will need to review the NetSuite error log (referenced above) for the details.
For vendors who invoice GitLab for multiple entities, all invoices are separated by subsidiary (due to audit standards). If the vendor onboards for the Coupa Supplier Portal (CSP), the vendor will only see the POs related to those entities, and will need to email the others. If you are a GitLab vendor who invoices for multiple entitites and you have any questions, please reach out to ap@gitlab.com.
Invoices requiring PO receipts or approval will appear in user's To Do list within Coupa. Users will also receive email notifications from Coupa (depending on user's notification setting in Coupa).
PO receipts notifications will enable users to "Create Receipt" by clicking on the button and entering the quantity received and receipt date. Please watch the End Users training video (starting at the 30:15 mark) for more information.
Approval notifications will enable users to reject or approve invoices by clicking on the appropriate button.
Top information to verify before approving an invoice
If there are issues with any of the above items, please tag @Accounts Payable Approval Group in the Comments section with details.
The invoice dispute process in Coupa enables the Accounts Payable team to request corrections on invoices from suppliers.
Invoices in "AP Hold", "Pending Action", "Pending Receipt", "On Hold", "Pending Approval" or "Rejected" statuses can be disputed to the supplier for corrections. Disputing an invoice requires a dispute reason and sends an email notification to the supplier contact on record and any additional listed recipients.
Once disputed, an invoice can be Withdrawn from Dispute by Accounts Payable or Voided; or Resolved by the supplier.
The invoice rejection process in Coupa allows the Accounts Payable team to make adjustments on invoices before restarting approvals, continuing approvals or disputing the invoice back to the supplier. This is an internal status that suppliers cannot see indicating that an approver or approval group rejected the invoice. Comments are required when rejecting an invoice - please provide as much detail/information as possible.
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 Effective 2021-06-01 we will begin to process in Coupa as well. These 2 systems will automatically record the transaction into NetSuite after the invoice has been approved by the corresponding business partner in the respective system.
If adding a new vendor, follow the bullets below before proceeding, otherwise skip to step 3
**.
Billable Expenses If you have an expense report that can be billed back to a customer please make sure to check the "billable" flag in Expensify along with tagging the customer name under the "customer" field in Expensify.
Supplier Payment Accounts (SPAs) are required in order to pay suppliers from Coupa Pay.
There are four different ways that suppliers will be able to provide their payment information:
If you are a GitLab vendor and you want to know more about how to update your CSP profile, check Coupa's Create or Update Your Profiles documentation.
After the supplier submits their supplier payment account information, it will transfer into Coupa automatically and create a supplier payment account record.
If the supplier is going through the SIM process, the approval for that supplier payment account will occur directly on the SIM External Form, and AP won't have to go into the supplier payment accounts to provide approval.
For more information regarding how to set up SPAs or Coupa Pay, please check out the lower section of our Coupa FAQ page.
Segregation of Duties: The creator of the Batch cannot be the releasor of the same batch regardless of the permissions they have.
A NetSuite error log identifying payment integration issues will be emailed to the Accounts Payable Team every Tuesday and Friday. The email is sent from Finance Systems Admins and the Subject is Coupa2NS Pay Payments Integration Log. Download the attached file and filter by Type = Error and Audit. Review the Details field to find the payment number that needs to be reviewed/corrected. For information regarding common errors and how to correct them, please see this file; under the column labeled Script search for Coupa Invoice Payment Integration. If any troubleshooting assistance is needed, please ask in the #coupa_help Slack channel.
There is also a View in Coupa that will list payments not exported to NetSuite. Under Payments, select View = Not Exported
However, there will be no details regarding the integration issue. You will need to review the NetSuite error log (referenced above) for the details.
Coupa is available via Okta. To access the platform:
Please note that every month all Coupa access will be reviewed and users who haven't been active in a period of 90 days will have their access removed. (Note that this number may vary depending on the license count for the current month)
If you need to request access again, please reopen your initial Access Request issue and tag the Finance Systems Admins team using @gitlab-com/business-technology/enterprise-apps/financeops in a comment.
If your job function requires you to submit purchase requests in Coupa, follow the below steps:
Individual_Bulk_Access_Request template.Best Practices
Due to the limited number of licenses available for Coupa, it is recommended that each department identify power users responsible for creating purchase requests on the team’s behalf.
Please refer to GitLab's Expense Policy for further details.
Entites included: GmbH, BV, PTY LTD, Ireland, IT BV and GK.
Further details on the Expense reimbursement process can be found here
Average days to action <= 3 business days
Number of days from when an team member's manager approves report to when AP analyst does final approval for payment or responds to team member 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 team member set up in Expensify < 3 business days
Have new team member set up in Expensify within 3 business days from team member start date.
When reducing spend, we will 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.
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 further approval is not required, then proceed to the Procurement "What are you buying" page for further instructions on the purchasing process at GitLab. Once those procedures are complete, have your vendor send their invoice to Accounts Payable: ap@gitlab.com. 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 do not make erroneous payments to vendors. All original invoices and payment receipts must be sent to Accounts Payable.
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/class to be set up please open this tracker and enter the information required for the General Ledger (GL) team to create the tag.
Create Classes In NetSuite:
Expensify will auto-sync any new "expense tags" on a daily basis, but if the Expensify admin wants to manually sync they can do so by following these steps:
Import new Classes/Tags In Expensify:
Please review this page for the current policy/procedures.
Please see the campaign expense guidelines in the Marketing handbook.
(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:
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.
Capitalization Thresholds
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.
Methodology
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 Floqast with an account reconciliation which includes details by individual asset purchased. The account reconciliation serves as an asset register. The accounting team captures each individual asset purchased with 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 process is governed by the following accounting policies:
Refer to Legal page for Related Party Transactions policy
Our ability to accomplish our Finance and Accounting mission of providing timely, fact-based information to drive business results as a public company depends on the participation of team members during certain critical times of year. Our accounting function provides critical, time based deliverables that directly impact our ability to support business growth and meet our public company obligations. These activities require the entire team’s support.
Team Members should prioritize taking time off to refresh and recharge outside of these critical windows. While these exact windows vary by team, generally we need all team members to support the last week of the quarter and first two weeks of the next quarter. Check with your manager if you are unsure what is applicable to your role. When these windows overlap a weekend (particularly the last day of the quarter) or public holiday/ Family and Friends day, we recommend team members work with their manager to reschedule the day off to a day outside of this critical end of quarter time period. If a team member is unavailable to work during this time period, they should provide their manager with at least one months’ notice whenever possible to allow for coverage to be arranged. When appropriate, we will create rotational coverage plans over holidays/weekends, while remaining in line with applicable jurisdictional requirements.
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:
Investment Objectives
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.
Effective 2022-04-01 a new Accounting Prepaid Automation Process has been implemented. Please click here to learn more about the process, which utilizes Coupa.
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 $5,000 USD
Identification and Recording of Prepaid Expenses Once a purchase request makes it through the company approval workflow, Accounting will take the following steps to ensure prepaid expenses are recorded accurately:
The amount involved is equal to or exceeds $5,000. Prepaid expenses below $5,000 must be recorded as period expense immediately as incurred.
The prepayment is for a time period greater than 12 months; (period of time is excluded for the Deposit of an event)
if an amount is equal or greater than $50,000 on a single item in one invoice, it can be capitalized if the prepayment time period spans across fiscal quarters.
Any deposits made for events in Marketing, Corporate or other departments of less than $5,000 USD will be recognized as an expense immediately on the day the invoice is received regardless of whether the event has taken place or not.
The $5,000 clip level normally applies per invoice or per item. However, situations may exist that would require exercising business judgement on a case by case basis (i.e. any clip level by total amount of purchase per vendor). Also, there are situations when each individual prepaid may not meet the clip level but as a whole, these prepayments are similar in nature and are purchased in a bulk and therefore, the total amount of all the prepaid should be combined and used to decide if the prepayment should be recorded. Any exceptions should be pre-approved by the Corporate Controller or PAO.
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. In order to meet industry standards for Month-End close deadlines the Finance and Operations teams are responsible to provide on Working Day -1 (ex. Friday July 30th = WD -1, Monday August 2nd = WD 1) the calculations, information, details and backup needed to support the accruals.
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:
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
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 Accounting Manager assigns each balance sheet account or groups of accounts to its respective preparer and reviewer using FloQast (Account Reconciliation Tool). The assignments are set once and will roll over into the next accounting period. The 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 FloQast 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:
FloQast will auto sign-off the recon on our behalf if the following is met:
If the balance changes after review, approval or auto sign-off the recon will be automatically unreconciled by FloQast 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.
Remaining performance obligations, or RPO, represent all future, noncancelable, contracted revenue under our subscription contracts with customers that has not yet been recognized, inclusive of deferred revenue that has been invoiced and noncancelable amounts that will be invoiced and recognized as revenue in future periods.
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
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, subsequent to the issuance of the preliminary reporting package, certain manual journal entries will not be recorded if they are immaterial. It is inefficient 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 |
|---|---|
| Accruals | $5,000 |
| Allocations between Departments (requires approval by FP&A team) | $25,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.
The main function of a Finance Class/Tag created in Netsuite is to track expenses, segmenting expenses into cost centers allows for greater control and analysis of total costs.
Campaign owners track costs associated with events, content, webcasts, Subscriptions, Memberships, Contracts etc. Campaign tags can be applied to Expensify reports, corporate credit card charges, and vendor bills processed by Accounts Payable. Campaign expenses that are incurred by independent contractors should be clearly noted with the appropriate tag and included in their invoices to the company.
If the tag needed will incur costs greater than $5K, a Coupa PO needs to be created. Please visit the Procurement page to identify which process is applicable to your purchase.
Marketers Please refer to : Campaigns and Programs
Other Departments/teams: Please navigate to this tracker and enter the information required for the GL team to create the tag.
The name can be any combination of characters that does not exceed the 31 digits allowed by the system. The suggested format for assigning a name to the class is YYYYYYMMDD_Vendor_Description. We suggest that it contain the date or the related fiscal year, the vendor's name and/or the description of the expenses.
Please be aware that once the class is created in Netsuite, the system automatically synchronizes with Expensify and Coupa to have the same classes created and available in each system.
If a tag has been created the owner is responsible for communicating and including the class in any related communication or expense.
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 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.
This section will be updated soon.
In Shopify:
In Avalara: