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.
Purpose of the application
Application used for generating leads, updating opportunities and generating quotes
Tool used for obtaining lead details
Application used for managing price masters, invoicing to customers and updating collections from customers
Application used for sale of GitLab merchandise to customers
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
** 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
Log in to Zuora and Salesforce.
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.
Then in Zuora, search for the corresponding customer subscription and open the record.
In SFDC check the chatter on the opportunity for any additional information.
Any special terms/language added to the quote should be approved in the chatter.
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
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).
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.
In SFDC check if the discount has been approved according to the matrix.
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’.
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.
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.
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.
Payment term - everything else than 30 needs to be approved by both CRO and CFO.
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
The signed quote should be dated - if not, reach out to Sales rep to get the signed quote updated and attached to the opp.
Amount - is the amount the same on the signed quote and the quote item in SFDC
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.
Check if Click Through EULA Required dropdown was set to Yes. EULAs are required for all reseller deals (New Business and Add-ons).
In Zuora check if the existing account is not on Silent communication profile for renewals and add-ons, especially important for reseller deals!
In Zuora check whether there are outstanding invoices older than 120 days?
In Zuora update the conversion rate for orders not billed through the US entity.
In SFDC check if the start date is up-to-date. If not confirm with the Sales rep.
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.
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
Is there an SLA/MSA in place? If so, is it referenced on the quote?
If the documentation requires countersignature, check if countersigned before processing.
If all the above that apply to the particular order are correct, approve the opportunity in SFDC and send the quote to Zuora.
If the opportunity doesn’t meet the requirements reject it and name all the reasons for rejection in your email.
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).
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.
In Zuora click on Create Bill Run and after ready populate the created invoice draft.
In Zuora on the invoice page add any additional information like end user name (and address) for reseller invoices where required.
Check the invoice PDF before posting and sending to the customer.
If there is a VAT in local currency on the invoice add the amount to the Additional Fields on the Invoice Page in Zuora.
Post the invoice.
Credit card payment? If so, process the card after billing.
In SFDC update entity, invoice status to Completed, invoice number, invoice date.
If it's an upgrade for GitLab.com portal needs to be updated manually.
Check if EULA was sent out - if it was not and should have been open an issue to have a EULA resent and cc the Sales rep.
Please note that EDU/OSS opportunities follow a slightly different process:
Check signature, amount, start date
Send to Zuora
Update entity and conversion rate if necessary in Zuora
Update account to Batch 50
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!)
Update the opportunity in SFDC
Points to note for professional services opportunities:
‘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
If SOW is in place it needs to be signed and countersigned if required
Cost estimate must be attached to the opportunity record prior to reporting as closed won
Quote object needs to be created to be sent to Zuora
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.
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.
Download the Accounts with Auto-generated Renewal Amendment report
Copy the subscription number to Zuora and search
Click on customer name and open in a separate tab
Click on CRM Account ID and open in a separate tab
On the Account page in Salesforce, look for any cases, activity history or chatter that needs review
On customer account page in Zuora, click the subscription and then invoice owner (Invoices for Resellers get invoiced on the invoice owner, not customer)
Click create bill run
Click on the BR#
Click invoice number once it loads
View invoice, then post it
Click the invoice number under generated invoices
Click more, than Process a Payment
If the payment goes through, go to the existing renewal opportunity:
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:
Create amendment to reverse auto-renewal under terms and conditions and change to current year
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
Send the below information via email to firstname.lastname@example.org
Company AP email
Billing contact name
Billing contact email
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.
Terms and Conditions - used to change the end date of a product
New Product - choose when adding a product
Update a product - choose when making a change to a current product
Remove a product - used when removing a product
Zuora Subscription Data Management
Subscriptions should only be cancelled with 45 days of the start. Exceptions can be made (see Support Workflows)
Subscriptions can be linked across multiple Zuora and SalesForce (SFDC) Accounts, but not SFDC Ultimate Parent Accounts.
All Zuora Accounts must be linked to a valid SFDC Account.
MRR can change historically due to customer behavior (renewals, cancellations, etc.)
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:
This field defines a unidirectional relationship that points to a separate subscription name.
A renewal subscription can start on the same or future day as the original subscription start date to which it is linked to, but never in the past.
Any number of subscriptions can point to the same renewal subscription as long as the time constraint is met.
A subscription may have any number of renewal subscriptions that it points to as long as the time constraint is met. This is a one-to-many relationship. Each renewal subscription to which the original subscription is linked is input in the field and are separated by two pipes.
For example, subscription A-S00009093 is linked to A-S00009096 || A-S00009095
Renewal subscriptions can point to subscriptions under separate Zuora Accounts
Renewal subscriptions can start 12 months or less after the original subscription. Practically, this is because a linkage of greater than 12 months has no effect on any relevant metrics (Retention or Yearly counts).
The process to make the linkage is as follows:
Cancel the old subscription in Zuora.
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
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.
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.
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.
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.
In NetSuite, click "Receive Payment" on the matched payment and invoice.
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.
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.
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:
Fill the "Journal Date" with the date that payment was received in the bank.
Fill the "Credit Account" with Stripe.
Fill the "Debit Account" with "Comerica Checking - GitLab Inc."
Leave "Name" blank.
Leave "Class" blank.
Fill the "Description" with "To record Stripe transfer (date of transfer)".
Posting a payment from a “bank customer”
Click on the “+” sign.
Click on “Receive Payment” under Customers.
Fill the "Payment Date" with the date payment was received.
Fill the "Payment Method" choose from the dropdown menu.
Fill the "Reference No." with the check # or bank reference # from incoming wire.
Fill the "Deposit to" with "Comerica Checking".
Fill the "Amount Received" with the amount received from the incoming wire.
Zuora generates automatic payment reminders at 7, 20, 30 and 45 days after invoice issuance
When an invoice reaches 30 days old an escalation email is sent to the account owner in sales.
When an invoice reaches 60 days old an escalation email is sent to the account owner in sales, the regional director and the CFO.
At 90 days old the account is put on support hold. The billing specialist sends an email to email@example.com with the customer information.
At 120 days old the account is put on credit hold and orders for that account can no longer be processed.
At 150 days old the account is sent to collections for recovery.
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
Accounts Receivable Performance Indicators
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
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
1. Requirement Identification / Requisition
2. Vendor Selection
3. Vendor Master Management
New vendors will be added into Tipalti by AP which will generate an onboarding email request to the vendor (Tipalti is an AP Payment Processing System that feeds data into NetSuite). New vendors are identified by an approved finance issue. If the vendor is not already set up in NetSuite it is considered a new vendor.
Once a vendor receives the onboarding request, they will need to onboard themselves into the portal and have to include their banking details and tax information which will all be stored in the secure portal.
Once a vendor onboards themselves in Tipalti the vendor record will auto feed into NetSuite and the vendor is created. Only after a vendor has onboarded themselves into Tipalti will they be ready to have invoices processed against their vendor record.
The vendor will receive auto generated instructions via email on how to submit their invoices to GitLab upon onboarding. They can submit their invoices directly to the Tipalti portal or send them to firstname.lastname@example.org.
If a vendor has any questions and/or ap inquiries please email them to email@example.com
Please note Tipalti go live is 2019-11-01; therefore, any already existing active vendors will be sent a one-time onboarding request from Tipalti via email. Vendors need to onboarded themselves into Tipalti in order to be paid. If you are a GitLab recurring vendor and did not get an onboarding email from Tipalti please reach out to firstname.lastname@example.org.
4. Order Management
5. Contract management
6. Invoice Accounting
Invoices will arrive by email to email@example.com or directly uploaded into the Tipalti Portal by the vendor.
The invoice is auto scanned into Tipalti (Tipalti is an AP Payment Processing System that feeds data into NetSuite)
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. AP will reference the finance issue in the header of the invoice when processing in Tipalti.
AP routes the invoice to the appropriate GitLab team-member via the Tipalit portal to obtain approval.
Once the requestor approves the invoice via Tipalti AP will be notified and Tipalti will automatically update the status of the invoice to approved and will record the transaction into NetSuite.
Tipalti will send auto notifications to the business partners if they do not approve an invoice timely. If an approver rejects the invoice AP will be notified and will act accordingly.
Entering a Bill (invoice) in NetSuite
Please note the below steps reference how to manually enter bills into NetSuite. Effective 2019-11-01 all AP invoices should be getting processed through Tipalti and will automatically record the transaction into NetSuite after the invoice has been approved by the corresponding business partner.
On the home page, click the “+” icon near the global search bar at the top of the screen and select “Bill."
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.
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.
Enter Bill number.
Go to the "Expense and Items" tab below to enter the expense details.
Select appropriate GL-account under the "Account" dropdown box. (Be sure to check whether the invoice represents a prepaid expense, fixed asset, etc.)
Enter Bill amount.
Select tax code, if applicable.
Enter department. (This must be entered if the account you selected in step 6 is an expense account)
Add attachments: Go to the "Communication" tab and find the "Files" subtab.
Click "New File.” A new window will appear, allowing you to select the file you wish to attach.
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)
In Google Drive, file invoice in the “Unpaid” folder.
7. Payment Process
Processing payment for invoices
On a weekly basis, AP will generate a batch in Tipalti of invoices due to be paid.
AP will submit the batch to the payment approvers through the Tipalti portal.
Management will review and approve the payment batches directly in the Tipalti portal.
Once payments are approved the vendors will be paid and Tipalti will automatically record the payment in NetSuite and change the status of the invoice to paid.
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
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.
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
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.
All other employees who are not paid directly through Expensify, payroll and/or a 3rd party vendor will be paid directly through GitLab's AP department 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. These reports will be paid through Tipalti (an AP payment processing tool)
Tipalti Paid Reports paid through GitLab's AP Department:
AP will send the employee an auto generated email from Tipalti with instructions on how to onboard. Only after an employee onboards themselves in Tipalti will payments be issued. (A one-time onboarding request will be sent to active employee's on 2019-10-28 to allow them time to onboard themselves in the portal). Any employee's after 2019-11-01 will be sent onboarding requests upon hire and/or upon first submission of an expense report.
Please Note: The timing of reimbursement can vary if you are being reimbursed directly from payroll, CXC, SafeGuard and/or iiPay
Expense Specialist Job Family Performance Indicators
Average days to action <= 3 business days
Number of days from when an employee's manager approves report to when expense specialist does final approval for payment or responds to employee in Expensify if there is a concern. (Approval for payment is not the reimbursement date.) This is calculated on a calendar month basis. The target for this is currently three business days.
Time to get a new employee set up in Expensify < 3 business days
Have new employee set up in Expensify within 3 business days from employee start date.
Travel and Expense Guidelines
When reducing spend, we'll not take the easy route of (temporarily) reducing discretionary spending.
Discretionary spending includes expenses like travel, conferences, gifts, bonuses, merit pay increases and summits.
By reducing in these areas we put ourselves at risk of increasing voluntary turnover among the people we need most.
Discretionary spending is always subject to questioning, we are frugal and all spending needs to contribute to our goals.
But we should not make cuts in reaction to the need to reduce spend; that would create a mediocre company with mediocre team members.
Instead, we should do the hard work of identifying positions and costs that are not contributing to our goals.
Even if this causes a bit more disruption in the short term, it will help us ensure we stay a great place to work for the people who are here.
Renting Cars in the United States and Canada
Third Party Liability
Purchase the liability insurance that is excess of the standard inclusion of State minimum coverage in the rental agreement at the rental agency. GitLab’s insurance policy provides liability insurance for rental cars while conducting company business, but it may be excess over any underlying liability coverage through the driver or credit card company used to purchase the rental.
Purchase the liability offered at the rental counter if there are foreign employees renting autos in the US or Canada. While workers' compensation would protect an injured US employee, other passengers may have the right to sue. To ensure that GitLab has protection when a foreign employee invites another person into the car we recommend the purchase of this insurance when offered at the rental counter.
Physical Damage – Collision Damage Waiver
Do not purchase the Collision Damage Waiver offered at the rental counter. GitLab purchases coverage for damage to rented vehicles.
If travel to Mexico is required, purchase the liability insurance for Mexico offered at the rental counter. You should verify that the rental agreement clearly states that the vehicle may be driven into Mexico and liability coverage will apply.
Renting Cars- Countries other than the US and Canada
Third Party Liability
Purchase the liability insurance offered at the rental counter when traveling outside the US and Canada. Automobile Bodily Injury and Property Damage Liability insurance are required by law in almost every country. Please verify this coverage is included with the rental agreement.
Physical Damage – Collision Damage Waiver
Purchase the Collision Damage Waiver or Physical Damage Coverage offered by the rental agency when traveling outside the US and Canada.
In the event of an accident resulting in damage to the rental car, the foreign rental agency will charge the credit card used to make the reservation with an estimated amount of repair costs if insurance is not purchased. If this happens, GitLab does not purchase Foreign Corporate Hired Auto Physical Damage Coverage to reimburse for damages.
Personal Use by Employee or Family Members of Business Auto Rentals
Coverage is not provided for personal use of automobiles or when family members are driving. Please evaluate whether your own personal automobile insurance provides an extension for this coverage. If it does not, or you are renting a vehicle outside the US or Canada or taking a US rented vehicle into Mexico, we recommend that you purchase the liability and physical damage coverage offered by the rental agency to protect your personal liability when not engaged in company business. GitLab will not pay for liability or damage to the rental vehicle resulting from personal use or use by non-employees.
In order to purchase goods and services on behalf of the company, you should first consult the Signature Authorization Matrix to determine the approval requirements. Note that this does not include travel expenses and other incidentals. These expenses should be self-funded then submitted for reimbursement within Expensify, or in the case of independent contractors, included in invoices to the company (per the guidelines above).
If approval is not required, then proceed and send the invoice to Accounts Payable (firstname.lastname@example.org). If approval is required, create a confidential issue in the Finance Issue Tracker and tag the required functional and financial approvers. Most importantly, the team member making the purchase request is ultimately responsible for final review and approval of the invoices. Final review and approval are critical process controls that help ensure we don't make erroneous payments to vendors. All original invoices and payment receipts must be sent to Accounts Payable.
Creation of Expense Tags
If you would like to track spend for a particular campaign, project and/or event you can do that through expense tag also known as classes in NetSuite. If you would like to request an expense tag to be set up please send your request to email@example.com and they can set it up for you.
In NetSuite go to Setup-Company-Classes-New
Add the name of the expense tag under Name
Under subsidiaries highlight GitLab Inc and check the box that states "Include in Children"
Expensify will auto-sync any new "expense tags" on a daily basis but if the Expensify admin wants to manually sync they can by following these steps:
Go to the Admin page and click on the Policies tab.
Select a policy and find the Connections subtab. The NetSuite connector is located on this page.
Click the Sync Now button for the NetSuite connector. The page will run a prompt showing sync status.
Once the syncing process is complete, go to the Tags subtab.
Search for the tag by name under classifications (i.e. the NetSuite profiles created in prior steps)
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.
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
In some cases, Expensify reports will show payment processor names (i.e. Stripe, PayPal) rather than the actual payee merchant, making it difficult to identify charges. This can be resolved by downloading your Amex statement from the portal, which contains greater detail.
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:
Expense Tags: If applicable, add expense tags under "Classifications". Common tag examples include company contributes, marketing campaigns, and professional service engagements.
Laptops/Equipment: Purchases of laptops and other assets in excess of $1,000 USD (per item) must include the name of the GitLab team-member for whom the asset was purchased.
Airfare/Travel: Purchases of flights, transportation, and lodging on behalf of other GitLab team-members must also include the name of the corresponding individual.
3. Attaching receipts
Any expense over $25 USD requires a legible receipt. No exceptions! Anyone not complying with policy may have their card cancelled.
4. Submit the report
Reports are due on the 3rd business day of each month. Failure to meet these policy guidelines on an ongoing basis will result in permanent cancellation of your card!
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.
To categorize an expense under an expense tag to track a specific marketing campaign, contribute expense and/or any special project you will do this under the "classifications" tag in Expensify.
10. Research & Development
Property, Plant and Equipment
Property, plant and equipment is the long-term asset or noncurrent asset section of the balance sheet. Following are the sub-processes:
2.Acquisition and Capitalisation
Capital Assets Policy
This policy establishes the minimum cost (capitalization amount) used to determine the capital assets recorded in GitLab's financial statements.
Capital Assets Defined
A “Capital Asset” is a unit of property that has an economic useful life extending beyond 12 months and was acquired (or in some cases, produced) for a cost of $5,000 (USD) or more. Capital Assets must be capitalized and depreciated for financial reporting purposes.
GitLab establishes $5,000 (USD) as the minimum amount required for capitalization. Any item with a cost below this amount 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.
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.
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).
Go to the team member in BambooHR.
Click on the Assets Tab.
Click Update Assets.
Enter Asset Category, Asset Description, Serial Number, Asset Cost, and Date Loaned.
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
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.
Purpose of the application
ERP system used by the Finance team to record the financial activity
Application used to automate and standardize reconciliation process
Stock option administration, capitalization table and equity management software platform
Application used for invoicing to customers
Record to report process is governed by the following accounting policies:
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.
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:
Morgan Stanley Smith Barney LLC
Comerica Securities, Inc.
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.
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.
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.
Money Market Funds - US Government/Treasury (AAA, No Sector Concentration, 50% Issuer Concentration)
Prepaid Expense Policy
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:
The Accounts Payable Administrator flags all bills that qualify as prepaid expenses during the normal course of processing bills in the AP mailbox.
The flagged bills are then analyzed and added to the asset register located in Google drive. Information includes expense category, department, benefit period, and amount to be amortized.
At the end of each month, the Accountant reconciles the prepaid additions to the general ledger, which includes verifying amortization schedules and amounts.
Amortization is recorded straight line based on a mid-month amortization method as follows:
If the first month of service begins on the 1st to the 15th of the month, a full month amortization will be recorded in the current month. If the first month of service begins on the 16th to the last day of the month, amortization will begin on the 1st day of the subsequent month.
Mid-Month Amortization Method does not apply to prepaid expenses with a monthly amortization equal to or greater than 50,000 USD or if the amortization if spread only over 1 period. If monthly amortization is equal to or more than 50,000 USD, the first month amortization will be calculated based on actual number of days where services were rendered.
Prepaid Not Paid: For any prepaid expenses not processed for payment, an adjustment for "prepaid not paid" is posted to the respective prepaid expense account and AP manual adjusment account (GL Account 2001). A prepaid expense is not treated as an asset if a liability remains in the AP sub-ledger. Prepaid not paid adjusments are performed on a quartly basis at minimum.
Any deposits paid which will be held for more than 12 months such as security deposits or deposits to retain consultants will be booked to Security & Other Deposits (GL Account 1620)
Prepaid Bonuses with a Clawback will be recoreded to Prepaid Bonus w/Clawback (GL Account 1152) and will be amortized in accordance with the bonus agreement terms, using the mid-month convention.
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
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.
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):
Contracts: Amounts due under contracts, including retainer fees. These items should be recorded as they become billable.
Professional Fees: This liability includes legal, tax, and aduit consulting and other professional fees.
Legal Contingencies: Pending or threatened litigation, and actual or probable settlement. Legal contingencies should be determined with the help of GitLab’s VP of Legal - Commercial, IP & Compliance.
Wages and Compensation:
Team Wages: This includes employee wages and independent contractor fees.
Commissions: Liabilities arising from commission obligations to team members who are eligible for commission compensation.
Bonuses: Liabilities related to bonus payments for GitLab team-members.
Taxes: All employment taxes required for statutory compliance that relate to the GitLab team.
Any other material obligation not mentioned above that is a liability of GitLab
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:
Risks of ownership passed to GitLab through receipt of goods or services.
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.
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.
Accruals are reversed in the next month and re-accrued the following month, as needed.
If payment is due prior to receiving goods or services, the amount should be accrued to prepaid expenses.
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.
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.
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.
This policy establishes the appropriate business use, responsibilities, and authorization of the Company’s credit card policy.
The purpose of this policy is to ensure that Company credit cards are used for appropriate business purposes and that adequate controls are established for day-to-day use.
The Company credit card policy applies to all employees who are approved to use a company credit card, including their managers.
This policy defines Company credit card access and use, and expense authorization and reimbursement for company employees.
This policy applies to all Company locations and departments.
Employees may be issued a Company credit card where the nature of their job responsibilities requires the purchase of services, business travel or supplies that cannot be obtained through an approved finance contract issue or be invoiced to Gitlab under normal procedures. The credit card should be used only as a last resort or where immediate purchase is needed (eg. at a conference, etc). No other person is permitted to use an approved Company credit card for charges other than the name of the employee that is shown on the credit card (exception under BizOps Card).
Authorization for the issuance of a credit card requires the approval of the Principal Accounting Officer.
Company credit cards may only be used for non-recurring business expenses and/or recurring if the vendor ONLY takes a credit card, even if asking for other payment methods. Company Credit Cards may not be used for personal expenses of any nature or where an approved finance contract issue process can be used with prior planning involved.
Purchases up to $10,000USD per transaction are allowed to be charged on a card and only require approval from the cardholder’s immediate manager upon submission of the monthly expense report.
Any purchase exceeding $10,000USD and up to $20,000USD will be allowed to be charged on the card but needs to have an approved finance issue with direct manager approval and/or executive level approval based on our authorization matrix. The approval needs to be attached to the charge in Expensify upon submission.
Anything over $20,000USD should not be charged on the card and has to go through the normal finance contract issue approval process.
Cards are only to be used for one-off purchases where pre-planning was not able to occur such as extra food at an event or last-minute materials used to host an event or unusual items at a marketing or sales events that were not anticipated and cannot be directly billed to accounts payable for said event.
Credit cards should NOT be used to charge sponsorships, annual subscriptions, deposits for events, recurring charges or anything that can be billed directly through our accounts payable department not to circumvent the finance contract issue process.
If you have a recurring charge and the vendor only takes credit card we can make an exception to allow the card to be charged if the per-transaction charge is under $10K USD. If over $10K USD provide an approved finance issue following the signature authority matrix. You can create a blanket issue for each calendar year.
The Corporate Travel Card is to only be used by TripActions to book approved travel on behalf of GitLab through the TripActions portal.
The BizOps IT Card is to only be used by BizOps to make purchases for new hire equipment following the Spending Company Money guidelines. This is the only card that is allowed to be shared in a secure vault to only BizOps IT personnel responsible for new hire purchases.
The misuse of an approved company credit card by the respective employee will result in disciplinary action and loss of the card.
Authorization for the issuance of a credit card can be obtained by initiating a finance issue and providing the justified business case of why the card is needed. The finance issue must be approved by the Principal Accounting Officer before a card can be issued. Assign the finance issue to the Sr. Accounting Operations Manager and Sr. Accounts Payable Specialist and request approval from the approved person. Please also copy your immediate manager on the issue so they are aware of the request.
If a card is granted, it is the responsibility of the employee to submit timely expense reports within three (3) business days following the credit card billing statement end date.
Monthly, American Express with auto-feed the credit card charges into Expensify under the cardholder name. It is the cardholder’s responsibility to attach each corresponding receipt to each charge and categorize the charge accordingly. Expense reports are to be submitted to accounting no later than the 3rd business day of each month following each statement end date. Failure to meet these policy guidelines on an ongoing basis will result in permanent cancellation of your card! See Company Credit Cards section in the handbook for more details on the submission process.
Once the cardholder submits their report to accounting, accounting will perform their audit review then will forward the report to the card owners’ immediate manager before the report can be processed. The manager is responsible to provide approval no later than 2 business days upon receipt of the report.
Accounting personnel will formally notify the employee’s manager of any outstanding expense reports when 1 business day overdue. When an expense report is 2 business days overdue the next level manager will be notified. Two late expense report submissions will result in permanent cancellation of your card!
The Company reserves the right to revoke the Company credit card at any time and will provide notice to an employee upon doing so.
Employees holding Company credit cards are responsible for adhering to this policy by:
Using the cards for their intended purpose.
Retaining and attaching receipts to all charges and providing explanations for all credit card transactions.
Timely submitting expense reports for any and all credit card transactions.
Managers are responsible for:
Limiting the use of Company credit cards to those employees who require a card for company business.
Reviewing and approving expense reports for credit card transactions used by their employees on a timely basis.
Accounting personnel are responsible for:
Ensuring all credit card transactions are properly authorized and are for business purposes only.
Processing payments for credit card statements on a timely basis and accruing for expenses in the proper accounting period.
Reviewing all expense reports and forwarding to the employee’s manager for final review and ensure all expenses are recorded accordingly.
Foreign Currency Translation Policy
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 used in the currency translation process vary across the three primary financial statement components:
Assets and Liabilities: Exchange rate between functional currency and reporting currency at period-end.
Income Statement: The average exchange rates during the period presented.
Equity: The historical exchange rate at the date when entry is made to shareholder's equity. Changes in retained earnings are based on historical exchange rates of each period's income statement.
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
This policy establishes GitLab’s guidelines regarding the structure, responsibilities and requirements underlying the chart of accounts (COA).
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:
Financial Planning and Analysis
Data & Analytics
Other departments who have shared functionalities within the financial system
The general ledger attributes subject to this policy will be defined by the Controller based upon factors including but not limited to:
Creating and maintaining consistency for the structure of accounts
Standard accounting policies and practices
Regulatory compliance requirements and reporting needs
Financial and operational reporting needs and requirements
External accounting and financial reporting requirements
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.
The COA is maintained in NetSuite. Changes to the COA can only be made by the Controller and/or Accounting Manager.
Account Reconciliation Policy
This policy applies to GitLab Inc. (“GitLab” or the “Company”) and all of its subsidiaries.
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”).
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:
Review all activities ensure activity is recorded properly.
Identify any reconciling items.
Upload any supporting documentation and/or add schedules as needed.
Certifies the recon in BlackLine which will auto route it to the reviewer(s) for their review and approval.
The reviewer(s) will ensure the following:
Ensures account reconciliations are prepared in compliance with this policy.
Ensures the account reconciliations are complete, accurate and appropriate.
Certifies the account reconciliation in the Blackline which will update the status of the recon to the reviewed/approved status. Once the recon is reviewed/approved the recon can’t be altered.
BlackLine will auto certify the recon on our behalf if the following is met:
Balance is zero
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:
Level of judgement required: risk increases as level of judgement required increases
routine/non-routine transactions: risk increases as amount of non-routine/non-standard processes required to record the activity increases
History of issues: risk increases as the number of audit-related adjustments, questions, restatements increases.
Complexity: risk increases due to business/system changes, new pronouncements, and new complex calculations that impact the balance sheet.
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.
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.
PS Fair Value Allocation Process:
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:
Any client with a license booking and PS booking within 30 days of each other.
Any client with multiple PS SKU’s with any one of the booking being within 30 days.
Identify Performance Obligation:
All the performance obligations/deliverables i.e. license, implementation, migration, training, etc. should be identified.
Stand-alone Fair Value:
Identify the stand-alone fair value for each performance obligation/deliverable which were identified in Step 2. Use/Refer to this template.
The total transaction price (combined value if multiple deals identified in Step 1) should be allocated in the ratio of their fair value calculated in Step 3.
Revenue should be recognized separately for each performance obligation/deliverable as per the Revenue Recognition policy.
The below details the current reporting structure for GitLab. This will be updated as our reporting evolves.
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.
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. The analysis can be found on the Finance Dashboard.
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.
The accounting team uses standard and advanced intercompany journal entries to complete their monthly close processes. In addition, mass loads are used to add or update vendor and employee records, for example. See link for templates.
JE and Mass Load templates
Journal entries are either manual or system generated. System generated entries would include elimination entries calculated by NetSuite when the elimination process is run as part of month end close or exchange rate adjustments based on final exchange rates. Manual journal entries are entered by the appropriate person in the Accounting department, depending on the nature of the entry. All manual journal entries require approval and posting by a second person in order to verify accuracy and that the appropriate documentation is included with the entry.
Manual journal entries are recorded in order to ensure our financial statements are materially accurate. As such, certain manual journal entries will not be recorded if they are immaterial, as it is inefficient and unnecessary to record entries that would not have a material impact on the users of our financial statements, unless these entries would be material if accumulated. Effective February 1, 2020, thresholds for manual journal entries are as follows:
Journal Entry Type
Allocations between Departments (requires approval by FP&A team)
Expensed in full in the month incurred if less than $10,000
Reclass between Accounts
Journal entry types not included above will always be recorded, no matter the amount. These include entries such as bank account activity, payroll, and taxes.
Employee stock options are recorded on a calendar quarterly basis. The puropse of this entry is to record the expense and allocate it between the appropriate departments.
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).
We will focus on the Expense Summary and Date tabs
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.
Sort the columns on the Date tab and delete all rows with a zero balance
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).
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.
Check that the total amount of the pivot table matches the amount on the Expense Summary tab.
Proceed to NetSuite to create a journal entry that matches the Expense Summary tab.
Date the journal entry using the last day of the quarter being closed.
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."
Be sure to fill in the Department attribute when adding lines to the journal entry.
The credit side of the entry only needs one line and uses GL "3015 Additional Paid in Capital- Stock Options"
Save the report used to calculate the journal entry and attach it to the entry within NetSuite.
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:
All team members who are involved in the close process are encouraged to add topics to the Month-End review doc
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
After the conclusion of the Month-End review, the team focuses on closing tasks
In addition to the Month-End review process, Accounting will coordinated the Month-End Close Checklist to ensure all closing tasks are completed.
The number of business days required to report final monthly financial results.
As a private company our target is 10 business days moving to 5 business days as a public company. This analysis can be found on the Finance Dashboard.
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.
Open Intercompany Calculation Sheet from Google Drive.
Add a new tab for the current month calculation.
Copy the contents of the previous month’s tab to the current month and change the date in cell B2.
Access NetSuite and open the income statement (found under the Reports and Financial tabs).
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.
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.
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.
Review the data for accuracy and verify that the formulas in the spreadsheet are up-to-date.
After reviewing, there should be no variances in column AL.
Update the balance in cell O100 so that the balance in cell R106 autocorrects to zero.
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.
Now, it’s time to create the intercompany vendor bills and customer invoices.
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.
The amounts in cells N113 and N119 will be used to create the intercompany transactions between GitLab BV and GitLab Inc.
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.
Complete the GitLab BV-GitLab Inc intercompany transactions by repeating step 15 for all of the required bills and invoices.
Next comes the GitLab BV-GitLab LTD transactions, which differ slightly from the GitLab BV-GitLab Inc transactions.
In NetSuite, download the GitLab LTD income statement in GBP.
Take the total overhead stated in GBP and add 6%.
This will be reported in the invoice from GitLab BV to GitLab LTD.
Once again, repeat step 15 for the GitLab BV-GitLab LTD transactions.
When the transactions are complete, you can check your work by verifying that the affected Revenue and COGS accounts offset each other.
Each calendar month the intercompany transactions between GitLab entities are settled in accordance with GitLab's Transfer Pricing Concept.
Accounting Manager prepares the balances in the Intercompany Settlement Google sheet
These balances derive from the AP and AR aging reports from Netsuite that are imported into the sheet
To the extent possible, intercompany positions in AP/AR betweeen the entities are netted
The Accounting Manager sends to Controller for review and approval in the Google sheet
The Accounting Manager sends to Director of Tax for review and approval in the Google sheet
The Accounting Manager sends to CFO for review and approval in the Google sheet
The Accounting Manager sends to CEO for review and approval in the Google sheet
Payments are subsequently queued for disbursement from the relevant bank accounts
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.