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

Accounting and Reporting

On this page


Accounting and Reporting

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

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

1. Customer account management and lead conversion to opportunity

Desktop procedures

2. Price master management

Desktop procedures

3. Quote creation

Desktop procedures

4. Reseller management

Desktop procedures

5. Contract management

Desktop procedures

6. Invoicing to customers

Desktop procedures

** 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.

Approving orders and invoicing

  1. Log in to Zuora and Salesforce.
  2. In SFDC go to the report: ‘Opportunities with Approval Pending’. Refresh if needed. 1 Open an opportunity, its associated documentation and the quote and add your name under Billing Specialist to let other team members know that you are working on it.
  3. Then in Zuora, search for the corresponding customer subscription and open the record.
  4. In SFDC check the chatter on the opportunity for any additional information.
  5. Any special terms/language added to the quote should be approved in the chatter.
  6. In SFDC check the entity of the signed quote - renewal/new business vs. add-on https://about.gitlab.com/handbook/business-ops/order-processing/#entering-quote-details
  7. If the entity of the account needs to be changed per renewal a new account for the customer or end user and reseller will need to be created in Zuora (before doing that check Zuora if the correct entity account already doesn’t exist there).
  8. If the new billing account for the change of entity has been created make sure to link the correct subscription ID (should be the subscription ID of the most recent amendment) in the EULA portal.
  9. In SFDC check if the discount has been approved according to the matrix.
  10. Sales reps can stack their discount on top of reseller discount. To view the reseller discount, go to the reseller account in SFDC > ‘Reseller Discount’.
  11. Address and email - check the quote vs. Zuora vs. portal - all three need to have the same sold to email address in order for the EULA/license to be sent out to the end user/customer.
  12. In order to proceed we need the full address - quotes without the full address will need to be updated and resigned by the customer/reseller.
  13. Valid VAT number is required if we bill to any EU countries - for the list check here. The VAT ID needs to be validated in http://ec.europa.eu/taxation_customs/vies/ This does not concern domestic transactions - NL > NL, DE > DE, UK > UK where VAT will be applied to the invoice at a country-specific rate.
  14. Payment term - everything else than 30 needs to be approved by both CRO and CFO.
  15. Check signature on the quote pdf - for signature/PO requirements refer to the handbook https://about.gitlab.com/handbook/business-ops/order-processing/#direct-deals-that-do-not-involve-resellers
  16. The signed quote should be dated - if not, reach out to Sales rep to get the signed quote updated and attached to the opp.
  17. Amount - is the amount the same on the signed quote and the quote item in SFDC
  18. If there’s a PO and it is less than quote - reject, PO will need to be updated - for any case (regardless signature on the quote) we only accept POs in USD.
  19. Check if EULA ticked off where required? EULAs are required for all reseller deals (New Business, Renewals, Add-ons).
  20. In Zuora check if the existing account is not on Silent communication profile for renewals and add-ons, especially important for reseller deals!
  21. In Zuora check whether there are outstanding invoices older than 120 days?
  22. In Zuora update the conversion rate for orders not billed through the US entity.
  23. In SFDC check if the start date is up-to-date. If not confirm with the Sales rep.
  24. On the quote check if the Zuora account ID isn't filled out for new business and is filled out for renewals and add-ons.
  25. Reseller - is the quote number on the PO? Does the PO refer to reseller's T&Cs? If so tag the Legal Team in chatter for approval if the PO is not coming from a pre-approved reseller - check here for the list of pre-approved resellers https://about.gitlab.com/handbook/business-ops/order-processing/#deal-desk-approval-process
  26. Is there an SLA/MSA in place? If so, is it referenced on the quote?
  27. If the documentation requires countersignature, check if countersigned before processing.
  28. If all the above that apply to the particular order are correct, approve the opportunity in SFDC and send the quote to Zuora.
  29. If the opportunity doesn’t meet the requirements reject it and name all the reasons for rejection in your email.
  30. After approving add PO number to the invoice if required by updating the subscription page in Zuora (if none provided and there was one before enquire with Sales rep).
  31. Authorized reseller - make sure the end user is on the same entity as the authorized reseller - do not change entity or invoice template for the authorized reseller.
  32. In Zuora click on Create Bill Run and after ready populate the created invoice draft.
  33. In Zuora on the invoice page add any additional information like end user name (and address) for reseller invoices where required.
  34. Check the invoice PDF before posting and sending to the customer.
  35. If there is a VAT in local currency on the invoice add the amount to the Additional Fields on the Invoice Page in Zuora.
  36. Post the invoice.
  37. Credit card payment? If so, process the card after billing.
  38. In SFDC update entity, invoice status to Completed, invoice number, invoice date.
  39. If it's an upgrade for GitLab.com portal needs to be updated manually.
  40. Check if EULA was sent out - if not enquire with the Fulfillment Team and cc the Sales rep.

Please note that EDU/OSS opportunities follow a slightly different process:

  1. Check signature, amount, start date
  2. EULA > Yes
  3. Send to Zuora
  4. Update entity and conversion rate if necessary in Zuora
  5. Update account to Batch 50
  6. Post the invoice automatically without sending if total 0 (if total different than 0 invoice needs to be checked prior to sending to the customer!)
  7. Update the opportunity in SFDC

Points to note for professional services opportunities:

  1. ‘Opportunity Record Type’ should be ‘Professional Services Only’. If it’s not, Sales Ops team needs to be informed so that it can be changed or a separate opportunity for PS can be created along with an opportunity for base or add-on products
  2. If SOW is in place it needs to be signed and countersigned if required
  3. Cost estimate must be attached to the opportunity record prior to reporting as closed won
  4. Quote object needs to be created to be sent to Zuora
  5. Read through SOW to bill accordingly - some PS opportunities require e.g. 50% of the amount billed upon execution (signing of the SOW), the 50% upon completion of the services.
  6. Should you bill the PS only partially leave the invoice on the ‘Pending Invoices’ view in SFDC as ‘In Progress’ so that further billing can be tracked. The progress on providing the services can be seen on the ‘Statement of Work’ report in SFDC. It is advisable to check the report monthly, if possible on the last day of the month.

Invoicing: Auto-Renewals

  1. Download the Accounts with Auto-generated Renewal Amendment report
  2. Copy the subscription number to Zuora and search
  3. Click on customer name and open in a separate tab
  4. Click on CRM Account ID and open in a separate tab
  5. On the Account page in Salesforce, look for any cases, activity history or chatter that needs review
  6. On customer account page in Zuora, click the subscription and then invoice owner (Invoices for Resellers get invoiced on the invoice owner, not customer)
  7. Click create bill run
  8. Click on the BR#
  9. Click invoice number once it loads
  10. View invoice, then post it
  11. Click the invoice number under generated invoices
  12. Click more, than Process a Payment
    • If the payment goes through, go to the existing renewal opportunity:
      • Click edit
      • Change stage to Closed won
      • Under subscription info: change start date (should match the real subscription date, may not be current date), opportunity term should be 12, click auto-renewal
      • Under Booking Info: Add the amount of the renewal to Amount, add the amount the subscription was previously billing to Renewal Amount, Renewal ACV is the total amount the subscription billed the previous term, click Web Portal Purchase
      • Under Invoice Info: add invoice number
    • If the payment doesn’t go through:
      • Unpost invoice
      • Cancel invoice
      • Create amendment to reverse auto-renewal under terms and conditions and change to current year
  13. Notes:
    • If an opportunity is closed/lost, the auto-renewal should be reversed
    • If customer has a renewal but they want to make changes to their subscription:
      • Cancel auto-renewal, Amendment name: Remove auto-renewal and reverse renewal
      • Amendment type – Terms and conditions
      • Change the term start date so that the end date is the current year
      • Check no under auto-renewal
      • Send chatter to account owner advising that auto-renewal is dropping so they can assist

Invoicing: One Time Events

  1. Send the below information via email to ar@gitlab.com
    • Company name
    • Company AP email
    • Address
    • Billing contact name
    • Billing contact email
    • Charge amount
    • Event name and subject

Amendments to Subscriptions

To amend a customer's account, choose one of the options below from the subscription page in Zuora.

  1. Terms and Conditions - used to change the end date of a product
  2. New Product - choose when adding a product
  3. Update a product - choose when making a change to a current product
  4. Remove a product - used when removing a product
  5. Renewal

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:

The process to make the linkage is as follows:

  1. Cancel the old subscription in Zuora.
  2. Copy and paste the new subscription in "Renewal Subscription" field with no trailing spaces.

Zuora subscription status 'active'

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

7. Invoice cancellations and refunds

Desktop procedures

How to initiate a refund request

  1. Complete and submit the following form:
    • https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000258393
    • A GitLab employee can submit a refund request on behalf of the customer or you can direct the customer to complete the form.
    • A support ticket will be created and will be routed to AR@.

How to process a refund in Zuora

  1. A refund request has been received by e-mail or refund opportunity in SFDC.
  2. Log in to Zuora.
  3. Search for the invoice that needs to be refunded.
  4. On the invoice screen, scroll down to "Transaction(s) associated to this Invoice" and click on the payment associated to the invoice to be refunded.
  5. On the payment screen, click on more and click on "Refund this payment."
  6. Create the refund.
  7. An auto-generated e-mail will be sent to the customer that the refund has been processed.
  8. The payment will be reversed on the invoice and there will be a balance due.
  9. Cancel the subscription in Zuora using the first day of the service period to be refunded.
  10. Create a bill run for the subscription cancellation.
  11. Post the invoice and transfer the credit balance.
  12. Apply the credit balance to the original invoice.
  13. Request a refund opportunity to be created in Salesforce if it hasn't been created already.
  14. Enter in the refund invoice number and the date of the refund on the refund opportunity.

How to process a partial refund in Stripe

  1. Log in to Stripe.
  2. Type in the cardholder’s name in the search field at the top of the screen.
  3. Click on the original charge that will be refunded.
  4. Click on the refund button.
  5. Enter in the amount to refund.
  6. Enter in the reason code.
  7. In the description field, enter the reason for the refund and include the invoice that was created in Zuora for the refunded amount.
  8. Click on refund.
  9. Go back to Zuora.
  10. Put the customer account in silent mode under "Communication Profile."
  11. Post the invoice draft.
  12. Transfer to credit balance.
    • Accounting Code: Stripe - Inc
  13. Put the customer account back into Default/B2B under "Communication Profile."
  14. Verify that the balance due is $0.00 on the refund invoice that was created.
  15. Manually e-mail the customer, do not use Zuora to create the email as you cannot update the contents. Include a screenshot of the partial refund from Stripe and attach a copy of the refund invoice.

8. Revenue recognition and accounting for other quote to cash transactions in Net Suite

Desktop procedures

9. Accounting for income from sale of merchandise

Desktop procedures

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.

  1. In Shopify, download the transaction report in CSV format (found under Orders, then Export).
    • This report contains swag shop revenue and tax data to be recorded in NetSuite.
  2. In portal used for swag download the orders report which should include cost for swag sold.
  3. Record the revenue, tax, cost and cash received. At times cost maybe estimated using a historical average.
  4. Record the tax collected in the Ava Tax Portal.
  5. Create a journal entry in NetSuite under the GitLab Inc subsidiary, using the last day of the month as the entry date.

10. Accounting for income on GCP referral

Desktop procedures

11. Accounts receivable

Desktop procedures

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.

  1. Login to Stripe dashboard and click on Payments under Transactions (left hand side). You will see a listing of the latest Stripe transactions listed by amount, Recurly transaction, name, date, and time. There is also an option to filter the report by clicking on XXX at the top left. Click on XXX to export to excel. This will give you a workbook area and also a breakdown of the fees which we will work on later.
  2. In NetSuite, click on the "Transactions" tab on the left.
    • Click on the orange "OPEN INVOICES " tab. This will bring up all open invoices listed by date, invoice #, customer, etc.
  3. Match invoice #s between the Stripe dashboard and NetSuite. If you click on a transaction in the Stripe dashboard, it will take you to a screen that shows more detail, including the invoice # being paid. You can work your way from the bottom up.
  4. In NetSuite, click "Receive Payment" on the matched payment and invoice.
  5. Receiving the payment
    • Enter the payment date, which is the payment date from Stripe dashboard.
    • Payment method = Credit Card.
    • Reference no. = "Recurly Transaction ID:" found under Metadata in Stripe dashboard.
    • Deposit to = Stripe.
    • NetSuite will auto-fill the payment amount with the entire balance due. No need to change this unless the payment amount from Stripe is different.
    • Click on "Save and Close".
    • Repeat the above for all the remaining invoices that were paid by credit card.
  6. Post a journal entry to record Stripe Fees.
    • In NetSuite, click on the "+" sign. Under "Other", select "Journal Entry".
    • It is okay to leave the journal date as long as it is within the month the fees were incurred. If not, change it to the last day of the month.
    • NetSuite will auto fill the journal number. Do not change.
    • Account #1 Entry
      • Fill the "Account #1" entry with "Credit Card Transaction fees".
      • Fill the "Debits" entry with the value from the Stripe report that was exported. The value will be the sum of "Column I" in the Stripe report, which is the fee amount. Be sure to only sum the rows which you just posted payments for.
      • Leave the "Credits" entry empty.
      • Fill the "Description" entry with "To record credit card transaction fees for period (enter the date range for the transactions posted)".
      • Leave the "Name" entry empty.
      • Fill the "Class" entry with "Sales".
    • Account #2 Entry
      • Fill the "Account #2" entry with "Stripe".
      • Leave the "Debits" entry empty.
      • The "Credits" entry will autofill. This should be the same amount as the "Debits" entry for Account #1.
      • The "Description" entry will autofill. This should be the same as the "Description" entry for Account #1.
      • Leave the "Name" entry blank.
      • Leave the "Class" entry blank.
      • Click "Save".

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:

  1. Fill the "Journal Date" with the date that payment was received in the bank.
  2. Fill the "Credit Account" with Stripe.
  3. Fill the "Debit Account" with "Comerica Checking - GitLab Inc."
  4. Leave "Name" blank.
  5. Leave "Class" blank.
  6. Fill the "Description" with "To record Stripe transfer (date of transfer)".
  7. Click "Save".

Posting a payment from a “bank customer”

In Netsuite:

  1. Click on the “+” sign.
  2. Click on “Receive Payment” under Customers.
  3. Fill the "Payment Date" with the date payment was received.
  4. Fill the "Payment Method" choose from the dropdown menu.
  5. Fill the "Reference No." with the check # or bank reference # from incoming wire.
  6. Fill the "Deposit to" with "Comerica Checking".
  7. Fill the "Amount Received" with the amount received from the incoming wire.

Cash Collections

  1. Zuora generates automatic payment reminders at 30, 60 and 90 days after invoice issuance
  2. When an invoice reaches 30 days old an escalation email is sent to the account owner in sales.
  3. When an invoice reaches 60 days old an escalation email is sent to the account owner in sales, the regional director and the CFO.
  4. At 90 days old the account is put on support hold. The billing specialist sends an email to support@gitlab.com with the customer information.
  5. At 120 days old the account is put on credit hold and orders for that account can no longer be processed.
  6. At 150 days old the account is sent to collections for recovery.
  7. Self-managed accounts that were cancelled before the end of term will be put on credit hold and reviewed before another purchase.

Account receivable provisions, bad debts and other period close adjustments Days Sales Outstanding (DSO) Average Accounts Receivable balance over prior 3 months divided by Total Contract Value (TCV) bookings over the same period multipied by 90 that provides an average number of days that customers pay their invoices. Link to a good definition and Industry guidance suggests the median DSO for SAAS companies is 76 days. Our target at GitLab is 45 days

12. Commission payouts to sales executives

Desktop procedures

Procure to Pay

Procure to pay is the process of requisitioning, purchasing, receiving, paying for and accounting for goods and services. It includes the following sub processes

1. Requirement Identification / Requisition

2. Vendor Selection

3. Vendor Master Management

4. Order Management

5. Contract management

6. Invoice Accounting

Invoices will arrive by email to ap@gitlab.com.

  1. AP locates the finance issue which corresponds with the invoice received to identify the invoice approver and the GL coding. If the invoice does not have a finance issue the AP team verifies that it is a recurring vendor and seeks approval from the prior invoice approver and ensures the approver is in line with the authorization matrix. If AP receives an invoice and it is not a recurring vendor and/or there is no approved finance issue, AP will not record the invoice in NetSuite. AP will then locate the team member requesting the service and will ask them to reference an approved finance issue before the invoice could be recorded in NetSuite.
  2. AP sends an email to the appropriate GitLab team-member to obtain approval.
  3. AP saves the email approval as a PDF copy to attach in NetSuite upon recording.
  4. AP records the invoice in NetSuite and attaches the invoice and email approval to the recorded record.

Entering a Bill (invoice) in NetSuite

  1. On the home page, click the “+” icon near the global search bar at the top of the screen and select “Bill."
  2. Select the appropriate vendor record. If adding a new vendor, follow the bullets below before proceeding, otherwise skip to step 3.
    • Enter the company name, email address, applicable subsidiary, physical address, payment terms, primary currency, and Tax ID. (Note that the address field is located under the "Address" tab, while the Tax ID, primary currency, and payment terms fields are located under the "Financial" tab)
    • Enter the banking information in the "Comments" field then click “Save.”
    • Go to the "+" icon at the top of the vendor record and select "Bill" from the dropdown box.
  3. Enter Bill date. The due date should auto-fill based on payment terms entered during vendor setup. If not, select the correct due date and update the vendor record after the bill has been entered and saved.
  4. Enter Bill number.
  5. Go to the "Expense and Items" tab below to enter the expense details.
  6. Select appropriate GL-account under the "Account" dropdown box. (Be sure to check whether the invoice represents a prepaid expense, fixed asset, etc.)
  7. Enter Bill amount.
  8. Select tax code, if applicable.
  9. Enter department. (This must be entered if the account you selected in step 6 is an expense account)
  10. Add attachments: Go to the "Communication" tab and find the "Files" subtab.
  11. Click "New File.” A new window will appear, allowing you to select the file you wish to attach.
  12. In the new window, select the "Attachments Received" folder in the dropdown box, then click "Choose File" to attach both a copy of the vendor bill and email approval. (The supporting email approval must be attached along with a copy of the invoice)
  13. Click "Save.”
  14. In Google Drive, file invoice in the “Unpaid” folder.

7. Payment Process

Processing payment for invoices

  1. On a weekly basis, AP will generate an AP aging summary from the NetSuite to identify invoices due to be paid.
  2. AP will Initiate payment(s) through the bank portal (Comerica/Rabobank) and will notify management that there are pending payment(s) to be approved. AP will provide a summary to the payment approvers of all payments along with the corresponding invoice support.
  3. Management will review and approve the payment directly in the bank portal.
  4. AP will verify the payment has cleared the bank.
  5. Upon verification of the payment AP will create the bill payment against the invoice in NetSuite to close the bill.

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.

8. Employee reimbursements - Expensify

Processing Expensify Reports

  1. Expensify will auto sync and record expense reports into NetSuite once the report is "final approved." "Final Approved," means it has been approved by the employee's manager and completed an audit review by a finance team member.
  2. Accounting will do a daily check to ensure all reports which are "final approved" are successfully synced. If any errors arise, AP will work out the errors until the report syncs into NetSuite.

Paying Expensify Reports

  1. Employee's in a US policy will be automatically reimbursed through Expensify after their report is "final approved" within 1-4 business days. Once an employee is reimbursed Expensify will auto sync the payment to the record to close the report as paid.

  2. Employee's outside of a US policy will be reimbursed with the normal weekly Friday AP payment run as long as their report was "final approved" no later than EOD Tuesday of that same week. Any report "final approved" on Wednesday to Friday of that week will be reimbursed the following Friday. Once an employee is reimbursed AP will create the payment in NetSuite against the record to close the report as paid.

Please Note: The timing of reimbursement can vary if you are being reimbursed directly from CXC, SafeGuard and/or iiPay

Travel and Expense Guidelines

Spend reduction

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.

Reimbursable Expenses

The procedure by which reimbursable expenses are processed varies and is dependent on contributor legal status (e.g. independent contractor, employee) and subsidiary assignment (Inc, LTD, BV, GmbH). Check with Payroll if you are unsure about either of these.

For information regarding the company expense policy, check out the section of our team handbook on Spending Company Money. The accounting team will review the expenses for compliance with the company travel policy. Exceptions will be escalated to the manager for review and approval. The CEO will review selected escalations at least annually.

Independent Contractors

Contributors who are legally classified as independent contractors in:

These team members should also consider the terms and conditions of their respective contractor agreements, when submitting invoices to the company.

Employees through PEO

Contributors who are employed through a PEO must submit their expense for reimbursement through Expensify. All expense reports must be approved by the 5th of each month to include in the current month payment.

Team members in France, Italy, and Spain must submit their expenses through:

Expense report for Spain team members must be approved by the 20th of the current month for team member(s) to get pay on the 15th of the following month.

Employees

Contributors who are on GitLab’s payroll are legally classified as employees. These team members will submit expenses in the Expensify application. Expense reports are to be submitted once a month, at least. If you were not assigned a user license as part of the onboarding process, you can request one by contacting People Operations Specialists. Additional information on getting started with Expensify and creating/submitting expense reports can be found here.

Expense reports for GitLab Ltd (UK) must be approved by the 14th of each month enable for it to include in the current month payroll.

Non-Reimbursable Expenses

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 (ap@gitlab.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.

Examples of things we have not reimbursed:

  1. Costume for end of summit party.
  2. Boarding expense for dog while traveling.
  3. Headphones costing $800 which were found to be in excess of our standard equipment guidelines.
  4. Batteries for smoke detector.
  5. Meals during the summit when team members opt out of the company provided meal option.
  6. Cellphones and accessories.

In accordance with Reimbursable Expense guidelines, independent contractors should note which expenses are Contribute related on their invoices, prior to submitting to the company.

In NetSuite:

  1. Create customer profiles in NetSuite for each legal entity (currently: Inc, BV, LTD, GmbH, PTY LTD). These will become the tags that are used in Expensify.
  2. Go to the global search bar and click the + icon to add customer profiles.
  3. Create a profile for each of the necessary entities and use the following tag naming format: Location Contribute 20XX Entity (e.g. New Orleans Contribute 2019 Inc). Be sure to do this for each legal entity.
  4. Log in to Expensify and follow the remaining steps.

In Expensify:

  1. Go to the Admin page and click on the Policies tab.
  2. There are six Expensify policies that we need to sync to NetSuite.
  3. Select a policy and find the Connections subtab. The NetSuite connector is located on this page.
  4. Click the Sync Now button for the NetSuite connector. The page will run a prompt showing sync status.
  5. Once the syncing process is complete, go to the Tags subtab.
  6. Search for the tag by name (i.e. the NetSuite profiles created in prior steps) and ensure that the switch is in the "On" position. All other tags should remain off as to avoid confusion for those tagging expenses.
  7. Create a test expense under each Expensify policy to verify that the summit tags work as planned. Again, check to ensure that this process has been completed for each policy in Expensify.

Company Credit Cards

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.

9. Summit Costs and other key expenses

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.

10. Research & Development

Property, Plant and Equipment

Property, plant and equipment is the long-term asset or noncurrent asset section of the balance sheet.Follwing are the sub-processes

1.Capital Budgeting

2.Acquisition and Capitalisation

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.

Capitalization Thresholds

GitLab establishes $5,000 (USD) as the minimum amount required for capitalization. Any item with a cost below this amount or an economic useful life of 12 months or less, is expensed on the date of purchase. For anything expensed, a technology inter-company cross charge is recorded monthly for items purchased on the US books on behalf of a non-US entity.

3.Retirement/Disposals

4.Depreciation/Amortisation

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.

Invoices and purchase receipts for capital assets are retained for a minimum of five years.

5.Fixed Asset Register Maintenance

The information is then entered into BambooHR (to track who has which piece of equipment) by IT ops, and it is included in the Fixed Asset Schedule by Finance (to track asset value and depreciation).

  1. Go to the team member in BambooHR.
  2. Click on the Assets Tab.
  3. Click Update Assets.
  4. Enter Asset Category, Asset Description, Serial Number, Asset Cost, and Date Loaned.
  5. This process is repeated for each asset purchased.

If a team member would like to purchase an asset from the company (i.e. a laptop), please email IT Ops to obtain the amount to be paid. This is derived from original cost less accumulated depreciation

6.Asset Tagging and Physical Verification

Asset Tracking

Items paid for by the company are property of the company.

Assets with purchasing value in excess of $1000 USD are tracked in BambooHR, for assets of lower value we rely on the honor system. These assets come to IT Ops attention by one of two ways: 1. IT Ops makes the purchase on behalf of the team member, or 2. the Finance team notices the line items on expense reports / invoices and passes this along to IT Ops.

7. Impairment and Revaluation

Record to Report

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

Accounting Policies

Record to report process is governed by the following accounting policies:

Investment Policy

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:

  1. Morgan Stanley Smith Barney LLC
  2. Comerica Securities, Inc.

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)

  1. US Government (AA+, No Sector Concentration, No Issue Concentration)
  2. Agency (AA+, 50% Sector Concentration, 10% Issuer Concentration)
  3. Money Market Funds - US Government/Treasury (AAA, No Sector Concentration, 50% Issuer Concentration)

Prepaid Expense Policy

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 $1,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:

  1. The Accounts Payable Administrator flags all bills that qualify as prepaid expenses during the normal course of processing bills in the AP mailbox.

  2. 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.

  3. 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.

  1. Finally, the balance is reviewed one last time when the Controller performs a review of the financials prior to closing the period.

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.

Accrued Liabilities Policy

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, to the greatest degree practical, in the period they are incurred. The accrual process should be completed on a monthly basis to ensure liabilities are recorded accurately in their respective periods.

The following items should be accrued monthly as necessary (note: this list is not all-inclusive):

Timing

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:

  1. Risks of ownership passed to GitLab through receipt of goods or services.
  2. The expense must have been incurred during the month being closed; that is, the product or service must have been received on or before the last day of the month in order to qualify as an expense.
  3. Even though an expense may have been initially budgeted in the month, it is not eligible for accrual unless the company received the product or service.
  4. Accruals are reversed in the next month and re-accrued the following month, as needed.
  5. If payment is due prior to receiving goods or services, the amount should be accrued to prepaid expenses.

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.

  1. Legal Professional Fees: Monthly templates are e-mailed by the 1st to all legal firms requesting them to complete with all outstanding bills and unbilled services as of that month end (ex. e-mails are sent by April 1st requesting services as of March 31st). The responses from all legal firms are complied and and reviewed with the VP of Legal - Commercial, IP & Compliance by the 5th, and accruals are made based on the responses and review. In addition, any potential legal contigencies are discussed during the monthly meeting with the VP of Legal and an accrual is recorded if the loss is deemed probable and the amount can be reasonably estimated.
  2. Tax and Audit Professional Fees: Similarlily e-mails with the template are sent to the tax and audit firms and the tax responses are compiled and reviewed with the Director of Tax and the audit firm responses are reviewed with the Accounting and External Reporting Manager by the 5th and appropriate accruals are made based on the review.

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

Foreign Currency Translation Policy

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.

Chart of Accounts Policy

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.

Account Reconciliation Policy

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.

Reporting

The below details the current reporting structure for GitLab. This will be updated as our reporting evolves.

Capital Consumption

TCV less Total Operating Expenses. This metric tracks net cash consumed excluding changes in working capital (i.e. burn due to balance sheet growth). Since the growth in receivables can be financed using cheap debt instead of equity this is a better measure of capital efficiency than cash burn. This analysis can be found on the Finance Dashboard.

Capital Consumption Ratio

IACV per Capital Consumed by calendar month. GitLab's target is to be > 2.

Cash

Defined as cash in the bank. Also counts short term securities that are readily convertable into cash within the next 90 days.

Cash Burn, Average Cash Burn and Runway

The change in cash balance from period to period excluding equity or debt financing. Average cash burn is measured over the prior three months. Runway is defined as the number of months based on cash balance plus available credit divided by average cash burn. Our target is that this metric is always greater than 12 months.

Line of Credit (LOC) Available

The amount of contractually committee line of credit extended by the bank that is not in default status.

Free Cash Flow (FCF)

Cash flow from operations as defined by GAAP less Capital Expenditures.

Gross Burn Rate

Total operating expenses plus capital expenditures.

Non GAAP Revenue (Ratable Recognition)

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.

Adding New GL Accounts

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.

Policy on Treasury activities

(Open, closing of bank accounts, approvals, authorization matrix etc)

Access management in NetSuite

Desktop procedures

Creation of Chart of accounts and GL accounts

Desktop procedures

Recording of Journal Entries

Journal Entries and Mass Loads for NetSuite

The accounting team uses standard and advanced intercompany journal entries to complete their monthly close processes. In addition, mass loads to add or update vendor and employee records are used, see link for templates. JE and Mass Load templates

Balance Sheet Reconciliation

Period End Closure and Reporting

Desktop procedures

Recording Employee Stock Option 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.

  1. Request a copy of the Carta report named "GitLab-Inc 20XX Equity Incentive Plan Grant Date Annual US GAAP Consolidated" from the CFO (the report should be in CSV/Excel format).
  2. We will focus on the Expense Summary and Date tabs
  3. On the Expense Summary tab, click on the journal entry amount to see column and tabs being referenced in the formula.
    • This should be column AX of the Date tab, and this column will be used to allocate the total expense between departments.
  4. Sort the columns on the Date tab and delete all rows with a zero balance
  5. Add a column to the Date tab with department information that corresponds to the employees referenced in column B (department information can be found in NetSuite).
  6. Create a pivot table using the data from column AX and the department column created in the previous step.
    • The pivot table should provide the amount of stock option expense attributable to each department.
  7. Check that the total amount of the pivot table matches the amount on the Expense Summary tab.
  8. Proceed to NetSuite to create a journal entry that matches the Expense Summary tab.
  9. Date the journal entry using the last day of the quarter being closed.
  10. The debit side of the entry uses GL "6077 Stock Compensation Expense" for all departments other than Cost of Sales which uses GL "5090 Stock Compensation Cost of Sales."
  11. Be sure to fill in the Department attribute when adding lines to the journal entry.
  12. The credit side of the entry only needs one line and uses GL "3015 Additional Paid in Capital- Stock Options"
  13. Save the report used to calculate the journal entry and attach it to the entry within NetSuite.
  14. Click Save and the entry is complete

Month-End Review & Close

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:

  1. All team members who are involved in the close process are encouraged to add topics to the Month-End review doc
  2. During monthly review meeting, the team reviews previous issues and adds new takeaway issues to Month End Review GitLab board. Issues specific to the Month-End review process can be found here
  3. After the conclusion of the Month-End review, the team focuses on closing tasks
  4. Repeat 1

In addition to the Month-End review process, Accounting will coordinated the Month-End Close Checklist to ensure all closing tasks are completed.

Average days to close KPI Definition

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.

Preliminary vs Final

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.

Intercompany transactions

Intercompany Calculation

  1. Open Intercompany Calculation Sheet from Google Drive.
  2. Add a new tab for the current month calculation.
  3. Copy the contents of the previous month’s tab to the current month and change the date in cell B2.
  4. Access NetSuite and open the income statement (found under the Reports and Financial tabs).
  5. Filter the income statement to the current month then further refine it by the desired subsidiary and set the column display to Subsidiary.
    • Note: The format of the income statement in NetSuite should look similar to that of the income statement in the Intercompany Calculation Sheet.
  6. Starting with the GitLab Inc. consolidated entity, copy the income statement data from NetSuite to the corresponding income statement in the Intercompany Calculation Sheet.
    • The balance under GitLab.com department should be combined with the Marketing department when transferring data to the Intercompany Calculation Sheet.
    • The GitHost balance should be reported under the No Department column.
  7. Repeat step 6 for the GitLab Inc (non-consolidated) and GitLab LTD subsidiaries. There is no need to perform this for GitLab BV as this balance will autofill.
    • For GitLab LTD, you’ll need to convert the income statement from GBP to USD:
      • Start by the running the consolidated income statement in NetSuite and changing the column display filter to Subsidiary.
      • Then take net income from the GitLab LTD column and divide this balance by the net income found in the GitLab LTD income statement. The resulting GBP-USD exchange rate should be used to convert the income statement.
  8. Review the data for accuracy and verify that the formulas in the spreadsheet are up-to-date.
  9. After reviewing, there should be no variances in column AL.
  10. Update the balance in cell O100 so that the balance in cell R106 autocorrects to zero.
  11. Update the exchange rate in cells O1110-O112 and cell O118 with this month’s rate*.
    • This exchange rate (USD to EUR) can be found in NetSuite under the Lists tab, then under the Accounting and Consolidated Exchange Rates subtabs.
  12. Now, it’s time to create the intercompany vendor bills and customer invoices.
  13. This can be tricky, so be sure to follow the workflow found in the Intercompany Calculation Sheet, starting under cell Q110 (the cells in column R reflect the exact names given in NetSuite, which is relevant for this exercise).
    • There will be two invoices and two bills issued between GitLab BV and GitLab Inc.
    • There will be one invoice and one bill issued between GitLab BV and GitLab LTD.
  14. The amounts in cells N113 and N119 will be used to create the intercompany transactions between GitLab BV and GitLab Inc.
  15. For increased speed and accuracy, start by finding an invoice (or bill) from the previous month, then use the Make Copy feature in NetSuite to create a duplicate.
    • This will allow you to review the data you are transferring, while comparing it to the previous month for additional guidance.
  16. Complete the GitLab BV-GitLab Inc intercompany transactions by repeating step 15 for all of the required bills and invoices.
  17. Next comes the GitLab BV-GitLab LTD transactions, which differ slightly from the GitLab BV-GitLab Inc transactions.
  18. In NetSuite, download the GitLab LTD income statement in GBP.
  19. Take the total overhead stated in GBP and add 6%.
    • This will be reported in the invoice from GitLab BV to GitLab LTD.
  20. Once again, repeat step 15 for the GitLab BV-GitLab LTD transactions.
  21. When the transactions are complete, you can check your work by verifying that the affected Revenue and COGS accounts offset each other.

Intercompany Settlement

Each calendar month the intercompany transactions between GitLab entities are settled in accordance with GitLab's Transfer Pricing Concept.

  1. Accounting Manager prepares the balances in the Intercompany Settlement Google sheet
  2. These balances derive from the AP and AR aging reports from Netsuite that are imported into the sheet
  3. To the extent possible, intercompany positions in AP/AR betweeen the entities are netted
  4. The Accounting Manager sends to Controller for review and approval in the Google sheet
  5. The Accounting Manager sends to Director of Tax for review and approval in the Google sheet
  6. The Accounting Manager sends to CFO for review and approval in the Google sheet
  7. The Accounting Manager sends to CEO for review and approval in the Google sheet
  8. Payments are subsequently queued for disbursement from the relevant bank accounts
  9. Signature authorization matrix
  10. Transaction is booked in NetSuite

Reporting

Types of Reporting:

Internal / Management Reporting

External Reporting

Financial Planning and Analysis (FP&A)

FP&A Handbook

Desktop procedures

Hire to Retire

Hire to Retire is the process covering employee recruitment, payroll processing and exit management. Below are the sub-processes:

Manpower Budgeting

Requisition & Sourcing

Candidate Assessment

Offer Management

On Boarding

Master Creation & Updation

Adding New Hire

  1. People Operations Analysts will notify Payroll when I-9 verification is completed
  2. Login to ADP as Administrator
  3. Select Process, HR, and Hire/Rehire
  4. Select Payroll Only (System) template
  5. Enter the legal name from Passport or SSN in BambooHR
  6. Select SSN for the Tax ID Type
  7. Enter Hire Date
  8. Select Gender
  9. Reason for Hire – New Position
  10. Enter Birth Date
  11. Company Code – 26X
  12. Select USA under the drop down under Countries
  13. Enter address
  14. Select Works from Home from the More Fields section on the right side
  15. Select Yes for Works from Home and Use Primary Address as the Work Address
  16. Select Ethnicity/Race ID Method under More Field
  17. Look up the Ethnicity under Job section in BambooHR
  18. Enter Job Tile and Report to Manager
  19. Select FT – Full Time under Worker Category
  20. Select team member’s lived in state for Location
  21. Select NAICS worker comp code – be sure to use 5302 for WA residents
  22. Enter work email address and check “Use For Notification”
  23. Select Salary or hourly under Regular Pay Rate
  24. Enter 86.67 hours for salary team members under Standard Hours and leave it blank for hourly members
  25. Enter the Worked in State, Lived in State, and SUI/SDI tax code
  26. Select Done
  27. Email the ADP Registration email to the team member(s)

Processing of Payroll For PEO (US and Non US)

One time payment

  1. Create a batch and name it accordingly
  2. Selecte the Bonus paydata grid
  3. Add employee
  4. Enter the earning type and amount
  5. Enter B pay frequency
  6. Enter #2, or 3 under pay #
  7. Enter W under Special Action

Processing of Payroll For Employee (US and Non-US)

GitLab Inc. Payroll Procedures

  1. People Ops Analysts will notify Payroll when new hires are added in BambooHR and I9 verification is completed
  2. Payroll admin adds new team member into ADP via Payroll system only template
  3. Email new hires with the ADP registration guide and ask them to update tax withholding and add direct deposit
  4. All additional payment requests must received by the payroll changes due date. The payroll schedule in ADP under Quick Links.
  5. Sr. People Ops Analyst updates salary, department, job title, and managers in ADP WFN before or by the due date
  6. Log into Betterment to run the current deferral rates report on the payroll processing date (5 days before check date)
  7. Update new deferral rates to team member's record in ADP WFN under deduction
  8. Lumity will send a benefits election change report by the 1st and the 15th of each month to payroll
  9. Update/Add these benefits elections in ADP (be sure to enter employee and employer benefits premium)
  10. Log into ADP WFN via Admin access
  11. Start a new payroll cycle under Process and Payroll
  12. Review the week # and check date
  13. All salary team members are set up with autopaid for 86.67 hours per check date.
  14. Create a batch for hourly employees, LOA, new hires, and/or termination
  15. Create a batch for one time payment (referral bonus, discretion bonus, commission, SDR bonus, and quarterly bonus) as check number #2 or 3 with Bonus frequency
  16. Create a batch for benefits corrections as needed
  17. Be sure to enter W under Special action column in the one time payment batch to cancel the calculation of GTL
  18. Generate payroll reports (employee changes, paydata summary) PDF format
  19. Send payroll to preview
  20. Review the preview register, make corrections as needed, and resend to preview
  21. Accept payroll

All hourly time sheets are kept on the Google Drive and shared with Finance. Each employee will populate the time sheet before the end of the pay cycle.

Lumity Payroll Processes for GitLab Inc.

Payroll Process

Payroll files will be provided to GitLab by Lumity to the People Operations Analyst and the Payroll and Payments Lead. Lumity will send a “Diff” payroll file and ADP Upload file on each Payroll Send Date. GitLab will review the payroll schedule and notify Lumity if send dates need to be changed. The ADP Upload file will only contain standard per pay period deduction amounts. GitLab will add one time catch-up and/or credits through ADP using the DIFF file.

401(k) Funding Process

  1. Run the "401(k) contribution by check date" report in ADP WFN for current check date (must be 2 days before the check date)
  2. Save a copy of the report in .xls format in this naming convention "401(k) contribution" check date
  3. Total the traditional and Roth contributions and verify the amounts with the ADP register total report
  4. Convert the file into .csv format
  5. Log in to Betterment, https://app.bettermentforbusiness.com/plan_managers/sign_in
  6. Select "Upload Payroll" on the landing page
  7. Select "Upload Payroll", select the csv file, enter check date, and select "Upload File"
  8. Betterment will verify the format of the uploaded file
  9. Verify the contribution amounts against the ADP register total report
  10. Approve the payroll contributions
  11. Save a copy of the confirmation email of ACH request from Betterment
  12. Upload the .cvs, .xls, ADP register total report, and email to Googledrive under GitLab Inc ->Payroll ->401k-Betterment -> year -> check date

Funding Process

Lumity will manage and fund all Discovery accounts. Employee and Employer funding will be taken from the payroll report provided to Lumity by GitLab.

GitLab BV Pay Slip Distribution Process

All GitLab BV employees receive their payslips within their personal portal of Savvy. They can login and download their payslip to their computer if needed.

UK, Belgium, Netherlands, Germany,& India Monthly Payroll Process

  1. Payroll changes due date to the payroll providers is 15th - 17th.
  2. People Ops Analysts will notify Payroll for all bonus payout requests, sick time, etc.
  3. Payroll changes are entered into a spreadsheet for commission, bonus, new salary, expense (only for UK) and password protected the file
  4. Payroll sends the payroll changes file to the local payroll providers.
  5. Local payroll providers will send the payroll report to payroll@gitlab.com for review and approval
  6. Payroll and Payments Lead will review and approve payroll before the 21st via email
  7. Payroll save and upload the payroll report to the GoogleDrive by month and under the right entity
  8. Payroll notify Financial Controller after approved payroll for Germany and Netherlands so he can queue up the ACH payments for net pay.
  9. Once processed the payslips are sent electronically directly to the team members for them to access via a password protected system.

Safeguard Payroll Process

Payroll cut off for sending changes is at the beginning of each month. The process for submitting changes is as follows:

  1. Payroll will make a copy of the Safeguard Payroll Changes sheet and add the changes
  2. Payroll will send a payroll changes file to Safeguard on the 9th day of the month. Due to confidentiality, the file will be password protected prior sending to Safeguard.
  3. The change sheet for that month should then be upload onto Google drive under the GitLab Inc => Payroll => PEO Safeguard

CXC Payroll Process

For Australia

The cutoff is typically the middle of the month and any salary changes will need to be sent by email along with a new Statement of Work (SOW). The process is as follows:

  1. Payroll will make a copy of the SOW template and complete the details.
  2. Once the SOW has been completed, verified and signed. Email the SOW to CXC
  3. Payroll will email CXC for commission and bonus.

For Canada

Team members in Canada are paid fortnightly. Changes will need to sent by email to the CXC contact see Australia section for location of contact details.

Commission Payment Process

  1. Each sales person will receive their own calculation template.
  2. Salesperson is to complete their monthly template four days (payroll will send reminder) prior to first payroll of the month. Upon completion, salesperson will ping a manager for review and approval.
  3. Approving manager will ping accounting upon approval.
  4. Accounting will review and reconcile paid vs unpaid invoices.
  5. Accounting will note in calculation template the amounts to be paid in commission.
  6. Accounting will ping payroll that commission calculation is complete.
  7. Commission will get pay on the 1st check date of the month for US team members and at the end of the month for all other countries.

Processing of Payroll For Contractors (US and Non US)

  1. For BV Contractors getting pay through iiPay, team member must submit their salary invoices through BambooHR and expense through Expensify by the 8th of each month
  2. To enter salary invoice in BambooHR:
    • Select "Request a Change", locate at the upper right corner in BambooHR
    • Contract Invoice
    • Enter Invoice date - current date
    • Invoice submit date - it should be same as invoice date
    • Invoice number - it should be incremental from the last invoice. If new team member, then it will be 1
    • Enter the monthly salary amount
    • Change the currency to match with the currency on the employment contract
    • Enter bonus or commission according to the position
    • Change the currency
    • Submit - there will be a message at the top of the page - "Your request was submitted successful"
  3. The invoice will submit to jnguyen@gitlab.com in Payroll for approval
  4. BambooHR will send an email after the invoice was approve or reject with the reason
  5. The invoice will be visiable in BambooHR at that time
  6. Note - Once Payroll approved the invoice, any corrections to that invoice must be edit by Payroll through correction request(s) email to payroll@gitlab.com
  7. For new hires starting after the 1st of each month, the pro-rated calculation is:
    • monthly salary / # of business days for that month * actual work days from the hire date
  8. All invoices will be approve by Payroll by the 9th of each month
  9. For expense reimbursement, team member will need to submit through Expensify and report(s) must be approved by managers by the 8th of each month
  10. Payroll will approve all expense reports by the 9th of each month
  11. If the 8th fall on the holidays or weekend, then the due date will move to the last business day before the 8th.
  12. For all new hires starting after the 8th of each month, then the current month payment will be pay with the following invoice as separate payment
  13. Note - all new team members will receive a testing payment from iiPay to validate their bank details prior to th 1st live payment. Please enter the bank details on the 1st day of employment.
  14. The required fields for bank details in BambooHR under Bank Information tab:
    • Bank Name
    • Beneficiary Name
    • Account Number (as needed due to each country's banking requirements)
    • Routing number (as needed due to each country's banking requirements)
    • IBAN - this is international Bank Account number. Each region will have different name for this number. Be sure to check with your bank
    • SWIFT (as needed or available due to each country's banking requirements)
    • Account type

Travel

Employee performance appraisal

Clearance & Exit Procedure

Full & Final Settlement

Regulatory

###Corporate Income Tax

###Sales Tax

Importing Swag Shop data to Avalara

In Shopify:

  1. Click on "Orders" in the left-hand toolbar.
  2. Select "Export" and the desired transaction history period.
  3. Download the report in CSV format.
  4. Copy the transaction data from the Shopify report to the Avalara Tax Import template located in the Google Drive.
    • Note that the import will fail if the columns that are highlighted green are left blank. Also check to ensure that the state and local tax data is entered into the correct columns. This is required for tax compliance.
  5. Save file for the remaining steps below.

In Avalara:

  1. Click on "Reports".
  2. Select the "Import Data" option.
  3. When prompted, choose the CSV import option.
  4. Check the import status report to ensure all transactions are successfully imported.

Wage Tax

Tax on stock options

Cash Forecasting and Tracking

  1. The Controller maintains the actual and forecast reporting for cash by entity.
  2. The google sheet is updating weekly and reconciled to Netsuite once per month.
  3. To find the internal google sheet search for "Cash Flow Forecast". If you need permission to access email the controller.