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 EULA ticked off where required? EULAs are required for all reseller deals (New Business, Renewals, 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 not enquire with the Fulfillment Team and cc the Sales rep.
Please note that EDU/OSS opportunities follow a slightly different process:
Check signature, amount, start date
EULA > Yes
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 email@example.com
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 30, 60 and 90 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 firstname.lastname@example.org 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 adjustmentsDays 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
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 email@example.com.
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.
AP sends an email to the appropriate GitLab team-member to obtain approval.
AP saves the email approval as a PDF copy to attach in NetSuite upon recording.
AP records the invoice in NetSuite and attaches the invoice and email approval to the recorded record.
Entering a Bill (invoice) in NetSuite
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 an AP aging summary from the NetSuite to identify invoices due to be paid.
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.
Management will review and approve the payment directly in the bank portal.
AP will verify the payment has cleared the bank.
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
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.
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
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.
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.
Contributors who are legally classified as independent contractors in:
New Zealand and Nigeria should include reimbursable expenses on the salary invoices to firstname.lastname@example.org.
All other contractors will submit their expense for reimbursement through Expensify. All expense reports must be approved by the 8th of each month to be include in the current month payment.
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:
Safeguard in-house expense reimbursement
GitLab payroll send the expense approval to Safeguard after the team member's manager approved the report
Team members send the original receipts to Safeguard (waiting on confirmation from Safeguard to by pass this step)
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.
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.
In order to purchase goods and services on behalf of the company, you should first consult the Signature Authorization Matrix to determine the approval requirements. Note that this does not include travel expenses and other incidentals. These expenses should be self-funded then submitted for reimbursement within Expensify, or in the case of independent contractors, included in invoices to the company (per the guidelines above).
If approval is not required, then proceed and send the invoice to Accounts Payable (email@example.com). If approval is required, create a confidential issue in the Finance Issue Tracker and tag the required functional and financial approvers. Most importantly, the team member making the purchase request is ultimately responsible for final review and approval of the invoices. Final review and approval are critical process controls that help ensure we don't make erroneous payments to vendors. All original invoices and payment receipts must be sent to Accounts Payable.
Examples of things we have not reimbursed:
Costume for end of summit party.
Boarding expense for dog while traveling.
Headphones costing $800 which were found to be in excess of our standard equipment guidelines.
Batteries for smoke detector.
Meals during the summit when team members opt out of the company provided meal option.
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.
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.
Go to the global search bar and click the + icon to add customer profiles.
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.
Log in to Expensify and follow the remaining steps.
Go to the Admin page and click on the Policies tab.
There are six Expensify policies that we need to sync to NetSuite.
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 (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.
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.
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. Common tag examples include company summits, 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.
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
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.
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.
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.
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)
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
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.
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
Hire to Retire is the process covering employee recruitment, payroll processing and exit management. Below are the sub-processes:
Requisition & Sourcing
Master Creation & Updation
Adding New Hire
People Operations Analysts will notify Payroll when I-9 verification is completed
Login to ADP as Administrator
Select Process, HR, and Hire/Rehire
Select Payroll Only (System) template
Enter the legal name from Passport or SSN in BambooHR
Select SSN for the Tax ID Type
Enter Hire Date
Reason for Hire – New Position
Enter Birth Date
Company Code – 26X
Select USA under the drop down under Countries
Select Works from Home from the More Fields section on the right side
Select Yes for Works from Home and Use Primary Address as the Work Address
Select Ethnicity/Race ID Method under More Field
Look up the Ethnicity under Job section in BambooHR
Enter Job Tile and Report to Manager
Select FT – Full Time under Worker Category
Select team member’s lived in state for Location
Select NAICS worker comp code – be sure to use 5302 for WA residents
Enter work email address and check “Use For Notification”
Select Salary or hourly under Regular Pay Rate
Enter 86.67 hours for salary team members under Standard Hours and leave it blank for hourly members
Enter the Worked in State, Lived in State, and SUI/SDI tax code
Email the ADP Registration email to the team member(s)
Processing of Payroll For PEO (US and Non US)
One time payment
Create a batch and name it accordingly
Selecte the Bonus paydata grid
Enter the earning type and amount
Enter B pay frequency
Enter #2, or 3 under pay #
Enter W under Special Action
Processing of Payroll For Employee (US and Non-US)
GitLab Inc. Payroll Procedures
People Ops Analysts will notify Payroll when new hires are added in BambooHR and I9 verification is completed
Payroll admin adds new team member into ADP via Payroll system only template
Email new hires with the ADP registration guide and ask them to update tax withholding and add direct deposit
All additional payment requests must received by the payroll changes due date. The payroll schedule in ADP under Quick Links.
Sr. People Ops Analyst updates salary, department, job title, and managers in ADP WFN before or by the due date
Log into Betterment to run the current deferral rates report on the payroll processing date (5 days before check date)
Update new deferral rates to team member's record in ADP WFN under deduction
Lumity will send a benefits election change report by the 1st and the 15th of each month to payroll
Update/Add these benefits elections in ADP (be sure to enter employee and employer benefits premium)
Log into ADP WFN via Admin access
Start a new payroll cycle under Process and Payroll
Review the week # and check date
All salary team members are set up with autopaid for 86.67 hours per check date.
Create a batch for hourly employees, LOA, new hires, and/or termination
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
Create a batch for benefits corrections as needed
Be sure to enter W under Special action column in the one time payment batch to cancel the calculation of GTL
Generate payroll reports (employee changes, paydata summary) PDF format
Send payroll to preview
Review the preview register, make corrections as needed, and resend to preview
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 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
Run the "401(k) contribution by check date" report in ADP WFN for current check date (must be 2 days before the check date)
Save a copy of the report in .xls format in this naming convention "401(k) contribution" check date
Total the traditional and Roth contributions and verify the amounts with the ADP register total report
Convert the file into .csv format
Log in to Betterment, https://app.bettermentforbusiness.com/plan_managers/sign_in
Select "Upload Payroll" on the landing page
Select "Upload Payroll", select the csv file, enter check date, and select "Upload File"
Betterment will verify the format of the uploaded file
Verify the contribution amounts against the ADP register total report
Approve the payroll contributions
Save a copy of the confirmation email of ACH request from Betterment
Upload the .cvs, .xls, ADP register total report, and email to Googledrive under GitLab Inc ->Payroll ->401k-Betterment -> year -> check date
Lumity will manage and fund all Discovery accounts. Employee and Employer funding will be taken from the payroll report provided to Lumity by GitLab.
Employer contributions will be funded each payroll ($50 per pay)
Missed ER contribution will not have a catch up (Employee enrolls late…Lumity will only fund ER contribution on the upcoming pay period. Any missed employer contributions will be disregarded)
Discovery will debit GitLab Bank account on each funding date
Max out is allowed
Funds will debit from the Discovery reserve account once the employee submits a claim
Discovery will contact GitLab if the reserve is low on funds
Dependent Care FSA
Funds will debit from the Discovery reserve account once the employee submits a claim
Discovery will contact GitLab if the reserve is low on funds
Funds will debit from the Discovery reserve account once the employee submits a claim
Discovery will contact GitLab if the reserve is low on funds
Employee payroll deduction will occur on the last payroll of the month and funded on the 1st of the following month
Funds will debit from the Discovery reserve account once the employee submits a claim
Discovery will contact GitLab if the reserve is low on funds
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
Payroll changes due date to the payroll providers is 15th - 17th.
People Ops Analysts will notify Payroll for all bonus payout requests, sick time, etc.
Payroll changes are entered into a spreadsheet for commission, bonus, new salary, expense (only for UK) and password protected the file
Payroll sends the payroll changes file to the local payroll providers.
Local payroll providers will send the payroll report to firstname.lastname@example.org for review and approval
Payroll and Payments Lead will review and approve payroll before the 21st via email
Payroll save and upload the payroll report to the GoogleDrive by month and under the right entity
Payroll notify Financial Controller after approved payroll for Germany and Netherlands so he can queue up the ACH payments for net pay.
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:
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.