会計と報告

このページには GitLab の会計・報告ポリシーが含まれており、公開可能なものです。内部プロセスについては、会計と報告の内部ハンドブックセクションをご覧ください。

受注から入金まで

顧客への請求

算出済み請求額

算出済み請求額は、貸借対照表に表示されている総繰延収益の逐次変化に収益を加算したものとして定義されます。

私たちは、算出済み請求額が財務パフォーマンスの有意義な指標を提供するとは考えていません。請求額は更新のタイミングのボラティリティ、契約期間を統合するアップグレード、および複数年のサブスクリプションの前払いによって影響を受ける可能性があります。

注文承認および請求プロセスについては、請求業務ページをご覧ください。

請求：単発イベント

1. 以下の情報を [email protected] 宛にメールで送信します。
   • 会社名
   • 会社の AP メールアドレス
   • 住所
   • 請求担当者名
   • 請求担当者メールアドレス
   • 請求金額
   • イベント名と件名

サブスクリプションの修正

顧客のアカウントを修正するには、Zuora のサブスクリプションページから以下のオプションのいずれかを選択します。

1. 条件と条件 - プロダクトの終了日を変更するために使用
2. 新規プロダクト - プロダクトを追加する際に選択
3. プロダクトの更新 - 現在のプロダクトに変更を加える際に選択
4. プロダクトの削除 - プロダクトを削除する際に使用
5. 更新

Zuora サブスクリプションデータ管理

基本的な前提

• サブスクリプションは開始から 45 日以内のみキャンセルすべきです。例外は設けることができます（サポートワークフローを参照）。
• サブスクリプションは複数の Zuora および SalesForce（SFDC）アカウントにリンクできますが、SFDC の Ultimate Parent アカウントにはリンクできません。
• すべての Zuora アカウントは有効な SFDC アカウントにリンクする必要があります。
• MRR は顧客の行動（更新、キャンセルなど）により過去にさかのぼって変更されることがあります。

新規アカウントと新規サブスクリプション

既存のアカウントに新しいサブスクリプションを追加するのではなく、Zuora に新規アカウントが必要な場合があります。これは sold-to の連絡先情報によって決まります。

顧客アカウントポータル内では、顧客は一度に一つの Zuora アカウントのみを閲覧できます。顧客がサブスクリプションを追加したい場合で連絡先情報が同じであれば、既存のアカウントにサブスクリプションを追加できます。

顧客が別の sold-to 連絡先に対する追加サブスクリプションを希望する場合は、すべての sold-to 連絡先がポータルにログインして自分のサブスクリプションを管理できるよう、新しい Zuora アカウントが作成されます。

更新サブスクリプションのリンク

顧客がサブスクリプションを更新すると、通常は新しいサブスクリプションが作成されます。これにより、一つのサブスクリプションが終了して別のサブスクリプションが開始されるため、サブスクリプションのドル保持率などの指標の計算が難しくなることがあります。これに対処するため、元のサブスクリプションとその更新サブスクリプション間でリンクが作成されます。

Renewal subscription フィールドはこのマッピングを作成するために使用されます。このフィールドには以下の制約があります：

• このフィールドは、別のサブスクリプション名を指す一方向の関係を定義します。
• 更新サブスクリプションはリンク先の元のサブスクリプション開始日と同日以降に開始できますが、過去の日付には開始できません。
• 時間的制約が満たされる限り、任意の数のサブスクリプションが同じ更新サブスクリプションを指すことができます。
• サブスクリプションは、時間的制約が満たされる限り、任意の数の更新サブスクリプションを指すことができます。これは一対多の関係です。元のサブスクリプションがリンクされる各更新サブスクリプションはフィールドに入力され、二つのパイプで区切られます。
  • 例えば、サブスクリプション A-S00009093 は A-S00009096 || A-S00009095 にリンクされています。
• 更新サブスクリプションは別の Zuora アカウントの下のサブスクリプションを指すことができます。
• 更新サブスクリプションは元のサブスクリプションから 12 ヵ月以内に開始できます。実際には、12 ヵ月を超えるリンクは関連する指標（保持率または年次カウント）に影響を与えないためです。

リンクを作成するプロセスは以下の通りです：

1. Zuora で古いサブスクリプションをキャンセルします。
2. 末尾スペースなしで新しいサブスクリプションを「Renewal Subscription」フィールドにコピー＆ペーストします。

Zuora サブスクリプションのステータス「アクティブ」

Zuora のアクティブサブスクリプションのステータスは、終了日との関連で確認する必要があります。終了日が将来の日付の場合、サブスクリプションはまだ期間内であり、顧客はプロダクトを使用できます。終了日が過去の日付の「アクティブ」サブスクリプションは、サブスクリプションが更新されておらず、顧客が終了日以降プロダクトにアクセスできないことを意味します。これらのサブスクリプションのキャンセルは手動プロセスであり、キャンセルの有無が他のプロセスに影響を与えないため、現時点では積極的にキャンセルしていません。また、アクティブステータスのサブスクリプションは顧客が CustomersDot で更新できます。

請求書のキャンセルと返金

ステップバイステップのプロセスについては、請求業務ページをご覧ください。

Stripe で部分返金を処理する方法

1. Stripe にログインします。
2. 画面上部の検索フィールドにカード名義人の名前を入力します。
3. 返金される元の請求をクリックします。
4. 返金ボタンをクリックします。
5. 返金額を入力します。
6. 理由コードを入力します。
7. 説明フィールドに返金の理由と、返金された金額に対して Zuora で作成された請求書を入力します。
8. 返金をクリックします。
9. Zuora に戻ります。
10. 「Communication Profile」の下で顧客アカウントをサイレントモードにします。
11. 請求書の下書きを転記します。
12. クレジット残高に振り替えます。
    • 会計コード：Stripe - Inc
13. 顧客アカウントを「Communication Profile」の下の Default/B2B に戻します。
14. 作成された返金請求書の残高が $0.00 であることを確認します。
15. Zuora を使用すると内容を更新できないため、顧客に手動でメールを送信します。Stripe からの部分返金のスクリーンショットと返金請求書のコピーを添付してください。

商品販売収益の会計処理

NetSuite でのスワッグショップ取引の転記

スワッグショップからの取引は毎日 Comerica 当座預金口座に送金され、毎月末に NetSuite に記帳する必要があります。

1. Shopify で CSV 形式のトランザクションレポートをダウンロードします（Orders の下の Export から）。

• このレポートには NetSuite に記録するスワッグショップの収益と税金のデータが含まれています。

1. スワッグ用のポータルで、販売されたスワッグのコストを含む注文レポートをダウンロードします。
2. 収益、税金、コスト、受取現金を記録します。コストは過去の平均を使用して推定することがあります。
3. Ava Tax ポータルで徴収した税金を記録します。
4. NetSuite で GitLab Inc 子会社の下で、月の最終日を入力日として仕訳を作成します。

売掛金

顧客回収の会計処理

現金受領

クレジットカード顧客

顧客がクレジットカードで支払った場合はこの手順に従ってください。 請求プロセスから、請求書を保存したときにまだ残高があったことを覚えているかもしれません。以下の手順で支払いを記録し、残高を解消します。

1. Stripe ダッシュボードにログインし、左側の Transactions の下の Payments をクリックします。金額、Recurly トランザクション、名前、日付、時刻でリストされた最新の Stripe トランザクションが表示されます。左上の XXX をクリックしてレポートをフィルタリングするオプションもあります。XXX をクリックして Excel にエクスポートします。これにより、後で取り組む手数料の内訳を含むワークブックエリアが得られます。

2. NetSuite で左側の「Transactions」タブをクリックします。

   • オレンジ色の「OPEN INVOICES」タブをクリックします。日付、請求書番号、顧客などでリストされたすべての未払い請求書が表示されます。

3. Stripe ダッシュボードと NetSuite の請求書番号を照合します。Stripe ダッシュボードのトランザクションをクリックすると、支払われている請求書番号などの詳細を示す画面に移動します。下から上に向かって進めることができます。

4. NetSuite で照合された支払いと請求書の「Receive Payment」をクリックします。

5. 支払いの受領

   • Stripe ダッシュボードからの支払い日を入力します。
   • Payment method = Credit Card。
   • Reference no. = Stripe ダッシュボードの Metadata にある「Recurly Transaction ID:」。
   • Deposit to = Stripe。
   • NetSuite は未払い残高全額で支払い額を自動入力します。Stripe からの支払い額が異なる場合を除き、変更する必要はありません。
   • 「Save and Close」をクリックします。
   • クレジットカードで支払われた残りのすべての請求書についても上記を繰り返します。

6. Stripe 手数料を記録するために仕訳を転記します。

   • NetSuite で「+」アイコンをクリックします。「Other」の下で「Journal Entry」を選択します。
   • 手数料が発生した月内であれば、仕訳日はそのままにしておいて構いません。そうでない場合は、月の最終日に変更します。
   • NetSuite は仕訳番号を自動入力します。変更しないでください。
   • Account #1 Entry
     • 「Account #1」エントリに「Credit Card Transaction fees」を入力します。
     • エクスポートされた Stripe レポートの値を「Debits」エントリに入力します。値は Stripe レポートの「Column I」の合計（手数料金額）です。先ほど転記した支払いに該当する行のみを合計するようにしてください。
     • 「Credits」エントリは空のままにします。
     • 「Description」エントリに「To record credit card transaction fees for period（転記したトランザクションの日付範囲を入力）」と入力します。
     • 「Name」エントリは空のままにします。
     • 「Class」エントリに「Sales」を入力します。
   • Account #2 Entry
     • 「Account #2」エントリに「Stripe」を入力します。
     • 「Debits」エントリは空のままにします。
     • 「Credits」エントリは自動入力されます。Account #1 の「Debits」エントリと同じ金額になるはずです。
     • 「Description」エントリは自動入力されます。Account #1 の「Description」エントリと同じになるはずです。
     • 「Name」は空欄のままにします。
     • 「Class」エントリは空欄のままにします。
     • 「Save」をクリックします。

このトランザクションは支払い義務を顧客から Stripe に移転します。Stripe が資金を GitLab の銀行口座に振り込む際に、Stripe からの支払い義務が解消されます。

Stripe から振込を受け取った際の Stripe からの支払いの転記

仕訳を転記します：

1. 「Journal Date」に銀行で支払いを受け取った日付を入力します。
2. 「Credit Account」に Stripe を入力します。
3. 「Debit Account」に「Comerica Checking - GitLab Inc.」を入力します。
4. 「Name」は空欄のままにします。
5. 「Class」は空欄のままにします。
6. 「Description」に「To record Stripe transfer（振込日付）」と入力します。
7. 「Save」をクリックします。

「銀行顧客」からの支払いの転記

NetSuite で：

1. 「+」アイコンをクリックします。
2. Customers の下の「Receive Payment」をクリックします。
3. 「Payment Date」に支払いを受け取った日付を入力します。
4. 「Payment Method」のドロップダウンメニューから選択します。
5. 「Reference No.」に小切手番号または着信電信送金からの銀行参照番号を入力します。
6. 「Deposit to」に「Comerica Checking」を入力します。
7. 「Amount Received」に着信電信送金から受け取った金額を入力します。

ステップバイステップの現金回収プロセスについては、請求業務ページをご覧ください。

売掛金引当金、貸倒損失、その他の期間末調整

売掛金パフォーマンス指標

Salesforce で案件が受注確定（Close Won）になった後、請求書が生成されるまでの時間 < 24 時間

Salesforce で案件が受注確定となった時点から請求書が生成されるまでの時間です。プロフェッショナルサービスはこのパフォーマンス指標から除外されます。これはカレンダー月単位で追跡されます。目標は 24 時間未満です。

請求書未払いに対する売掛金プロセス

1. 請求＆収益チームは月次ベースで AR エイジング（売掛金の経過日数）をレビューします。期限後 90 日以上の残高の 50%、および期限後 120 日以上の残高の 100% が貸倒引当金として引当金計上されます。貸倒損失費は認識済み収益に基づいて記録され、将来の収益認識が停止され、繰延収益が NetSuite レベルですべて取り消されます。
2. 引当金計上された請求書に関連するコミッション経費の将来償却も、収益認識パターンとの整合を確保するために停止する必要があります。
3. 貸倒引当金は、将来的に損失処理される可能性があるものを可視化するため、月次ベースでセールスオペレーションと共有されます。
4. 四半期ごとに、シニア請求マネージャーと収益ディレクターが回収不能な滞留請求書を決定します。四半期末の 10 日前に Issue を作成し、署名権限マトリックスに従って請求書の損失処理の承認を求め、セールスオペレーションのシニアディレクターに通知します。セールスオペレーションは四半期末までに承認された損失処理の解約機会を SFDC で作成し、元の請求と収益を取り消すために Zuora と同期されます。セールスオペレーションはコミッションを相応に返還します。
5. 収益チームは Zuora で処理された損失処理をレビューして正しい収益取り消しを確認し、NetSuite で MJE を計上して貸倒引当金への影響を再分類します。
6. 請求書が損失処理された顧客については、将来の取引でディスカウントやクレジットを考慮しません。
7. 損失処理後に請求書の支払いを受け取った場合、損失処理は取り消され、関連するコミッションが回復されます。

購買から支払いまで

購買から支払いまでは、商品とサービスの要求、購入、受領、支払い、および会計処理のプロセスです。調達および買掛金部門の以下のサブプロセスを含みます。

ベンダーマスター管理

• ベンダーがまだ NetSuite に設定されていない場合は、新規ベンダーとみなされます。
• 新規ベンダーの法的実体に応じて、Coupa にオンボーディングされます。

新規ベンダーオンボーディング - Coupa

Coupa は、購入要求プロセスを合理化し、承認付きのワークフローを開始し、発注書を可能にする購買から支払いまでのシステムです。段階的アプローチで展開予定で、米国とオランダの法人（GitLab Inc、Federal、IT BV、BV）がフェーズ I（2021-06-01）に、残りの法人がフェーズ II（2021-12-13）に含まれます。

Coupa の詳細については、FAQ ページをご覧ください。

Coupa へのベンダー追加方法：

1. Coupa ユーザーは誰でも新規サプライヤーリクエストフォームを使用して新規サプライヤーをリクエストできます。
   • 詳細なガイドについては、Coupa での新規サプライヤーのリクエスト方法をご確認ください。
2. 新規サプライヤーリクエストが承認されると、追加情報を収集するための外部サプライヤーフォームがサプライヤーに自動送信されます。
   • サプライヤーはフォームに記入して返送する必要があります。
3. サプライヤー提出後、外部フォームはレビューと承認のために買掛金承認グループにルーティングされます。
4. 承認後、サプライヤーの詳細が NetSuite に統合されます。サプライヤーが NetSuite に正常に作成されると、Coupa に反映されて新規サプライヤーの作成が完了します。その後、サプライヤーは購入リクエストと請求書の作成時に利用可能になります。

請求書の会計処理

NetSuite での請求書（invoice）の入力

以下の手順は NetSuite に請求書を手動入力する方法を参照しています。2019-11-01 以降、すべての AP 請求書は Tipalti で処理されています。2021-06-01（Coupa フェーズ I）および 2021-12-13（Coupa フェーズ II）以降、AP 請求書は Coupa で処理されます。これらのシステムは、請求書がそれぞれのシステムで対応するビジネスパートナーによって承認された後、NetSuite にトランザクションを自動記録します。

1. NetSuite ホームページで、画面上部のグローバル検索バー近くの「+」アイコンをクリックし、「Bill」を選択します。
2. 適切なベンダーレコードを選択します。新規ベンダーを追加する場合は、続行前に以下の手順に従ってください。そうでない場合はステップ 3 に進みます。
   • 会社名、メールアドレス、該当する子会社、住所、支払い条件、基本通貨、Tax ID を入力します。（住所フィールドは「Address」タブにあり、Tax ID、基本通貨、支払い条件フィールドは「Financial」タブにあります）
   • 「Comments」フィールドに銀行情報を入力し、「Save」をクリックします。
   • ベンダーレコード上部の「+」アイコンに移動し、ドロップダウンボックスから「Bill」を選択します。
3. 請求日を入力します。期日はベンダー設定時に入力した支払い条件に基づいて自動入力されます。そうでない場合は、正しい期日を選択し、請求書が入力・保存された後にベンダーレコードを更新します。
4. 請求書番号を入力します。
5. 下部の「Expense and Items」タブに移動して経費の詳細を入力します。
6. 「Account」ドロップダウンボックスから適切な GL 勘定を選択します。（請求書が前払い費用、固定資産などを表すかどうかを確認してください）
7. 請求金額を入力します。
8. 該当する場合は税コードを選択します。
9. 部門を入力します。（ステップ 6 で選択した勘定が経費勘定の場合は必ず入力してください）
10. 添付ファイルの追加：「Communication」タブに移動し、「Files」サブタブを見つけます。
11. 「New File」をクリックします。添付するファイルを選択できる新しいウィンドウが表示されます。
12. 新しいウィンドウで、ドロップダウンボックスから「Attachments Received」フォルダーを選択し、「Choose File」をクリックしてベンダーの請求書のコピーとメール承認の両方を添付します。（サポートするメール承認は請求書のコピーとともに添付する必要があります）
13. 「Save」をクリックします。
14. Google Drive で、請求書を「Unpaid」フォルダーに保存します。

Coupa での請求処理

Coupa は調達および請求ツールです。商品/サービスの購入リクエストが Coupa で開始される必要があるのと同様に、請求書も Coupa で作成・承認されます。

Coupa の請求書は 4 つの異なるチャンネルで作成できます：

• Coupa Supplier Portal（CSP）
  • サプライヤー専用の無料ウェブベースのポータル。
  • サプライヤーは CSP Coupa 受信箱内で PO を受け取り、PO から請求書への変換（PO Flip）を行い、すべての PO/請求書の完全な履歴を確認できます。
  • サプライヤーによって CSP 請求書が提出されると、Coupa が承認ワークフローをトリガーします。
• Supplier Actionable Notification（SAN）
  • サプライヤーは Coupa PO SAN メールから直接操作（PO から請求書への変換）します。
  • Coupa/CSP への登録/サインインは不要で、すべてのサプライヤー（メールアドレスがあれば）が利用できる無料サービスです。
• cXML
  • cXML 請求機能を持つ「高接触」サプライヤー（Amazon、CDW など）が PO を受け取り、請求書を直接送信します。
  • パンチアウトと組み合わせて効果的に機能します。
• Coupa UI での手動入力
  • 「Flip PO」オプションで Coupa PO からデータをコピーして請求書フィールドを事前入力することで、入力を迅速化します。
  • 非 PO バックドの請求書の手動入力。

Coupa 統合 - 請求書のトラブルシューティング

請求書の統合問題を特定する NetSuite エラーログは、毎週火曜日と金曜日に買掛金チームにメールで送信されます。メールは Finance Systems Admins から送信され、件名は Coupa2NS Invoices - Integration Log です。添付ファイルをダウンロードし、Type = Error と Audit でフィルタリングします。Details フィールドをレビューして、確認/修正が必要な請求書番号/伝票番号を見つけます。一般的なエラーとその修正方法については、こちらのファイルをご覧ください。Script 列で Coupa Invoice Integration を検索してください。トラブルシューティングの支援が必要な場合は、#coupa_help Slack チャンネルでお問い合わせください。

NetSuite にエクスポートされていない請求書をリストする Coupa のビューもあります。Invoices の下で View = Not Exported を選択します。

ただし、統合の問題に関する詳細は表示されません。詳細については NetSuite エラーログ（上記参照）をレビューする必要があります。

Coupa での請求書の承認

PO 受領または承認が必要な請求書は、Coupa 内のユーザーの To Do リストに表示されます。ユーザーは Coupa からも（Coupa のユーザー通知設定に応じて）メール通知を受け取ります。

PO 受領通知により、ユーザーはボタンをクリックして「Create Receipt」を行い、受領数量と受領日を入力することができます。詳細については、エンドユーザートレーニング動画（30:15 から）をご覧ください。

承認通知により、ユーザーは適切なボタンをクリックして請求書を却下または承認できます。

Coupa での請求書の異議申し立て

Coupa の請求書異議申し立てプロセスにより、買掛金チームはサプライヤーに請求書の修正をリクエストできます。

「AP Hold」、「Pending Action」、「Pending Receipt」、「On Hold」、「Pending Approval」、または「Rejected」ステータスの請求書は、修正のためにサプライヤーに異議申し立てを行うことができます。請求書の異議申し立てには異議の理由が必要で、レコードにあるサプライヤー担当者と追加の受信者にメール通知が送信されます。

異議申し立て後、請求書は買掛金が異議から取り下げるか、無効にするか、またはサプライヤーが解決できます。

Coupa での請求書の却下

Coupa の請求書却下プロセスにより、買掛金チームは承認を再開始するか、承認を継続するか、または請求書をサプライヤーに異議申し立てする前に、請求書の調整を行うことができます。これはサプライヤーが確認できない内部ステータスであり、承認者または承認グループが請求書を却下したことを示します。請求書を却下する際はコメントが必要です。できる限り詳細/情報を提供してください。

NetSuite への請求書の手動入力

以下の手順は NetSuite に請求書を手動入力する方法を参照しています。2019-11-01 以降、すべての AP 請求書は Tipalti で処理されるべきであり、2021-06-01 以降は Coupa でも処理を開始します。これらの 2 つのシステムは、それぞれのシステムで対応するビジネスパートナーによって請求書が承認された後、NetSuite にトランザクションを自動記録します。

1. NetSuite ホームページで、画面上部のグローバル検索バー近くの「+」アイコンをクリックし、「Bill」を選択します。
2. 適切なベンダーレコードを選択します。

   新規ベンダーを追加する場合は、続行前に以下の手順に従ってください。そうでない場合はステップ 3 に進みます。

   • 会社名、メールアドレス、該当する子会社、住所、支払い条件、基本通貨、Tax ID を入力します。（住所フィールドは「Address」タブにあり、Tax ID、基本通貨、支払い条件フィールドは「Financial」タブにあります）
   • 「Comments」フィールドに銀行情報を入力し、「Save」をクリックします。
   • ベンダーレコード上部の「+」アイコンに移動し、ドロップダウンボックスから「Bill」を選択します。

3. 請求日を入力します。期日はベンダー設定時に入力した支払い条件に基づいて自動入力されます。そうでない場合は、正しい期日を選択し、請求書が入力・保存された後にベンダーレコードを更新します。
4. 請求書番号を入力します。
5. 下部の「Expense and Items」タブに移動して経費の詳細を入力します。
6. 「Account」ドロップダウンボックスから適切な GL 勘定を選択します。（請求書が前払い費用、固定資産などを表すかどうかを確認してください）
7. 請求金額を入力します。
8. 該当する場合は税コードを選択します。
9. 部門を入力します。（ステップ 6 で選択した勘定が経費勘定の場合は必ず入力してください）
10. 添付ファイルの追加：「Communication」タブに移動し、「Files」サブタブを見つけます。
11. 「New File」をクリックします。添付するファイルを選択できる新しいウィンドウが表示されます。
12. 新しいウィンドウで、ドロップダウンボックスから「Attachments Received」フォルダーを選択し、「Choose File」をクリックしてベンダーの請求書のコピーとメール承認の両方を添付します。（サポートするメール承認は請求書のコピーとともに添付する必要があります）
13. 「Save」をクリックします。
14. Google Drive で、その法人の「Entered」フォルダーに請求書を保存します。

支払いプロセス

請求可能経費

顧客に請求可能な経費報告書がある場合は、Navan で「billable」フラグを確認し、Navan の「customer」フィールドに顧客名をタグ付けしてください。

Coupa での請求書の支払い処理

Coupa Pay からサプライヤーへの支払いには、Supplier Payment Accounts（SPA）が必要です。

サプライヤーが支払い情報を提供できる方法は 4 つあります：

• Smart Onboarding Form：Coupa Supplier Portal 内のネイティブ Coupa 機能で、サプライヤーが銀行情報を登録できます。
• SIM（Supplier Information Management）フォーム：GitLab が新規サプライヤーをオンボーディングする際、外部フォームの一部として、ベンダーの送金先情報と銀行口座情報を記録するセクションがあります。（これは大多数の GitLab サプライヤーが銀行情報を提供する場所です）。
• Coupa Supplier Portal（CSP）法的実体セクション：主に、サプライヤーが銀行口座情報を変更する必要がある場合や更新を行う必要がある場合に使用されます。ベンダーは Coupa Supplier Portal プロファイル内で直接管理し、新しい法的実体（新しい銀行口座に関連付けられる）を追加するか、既存のものを調整できます。
• 請求セクション：何らかの理由でサプライヤーが最初の請求書を提出する際に銀行情報を提供していない場合、Coupa で新しいサプライヤー支払いアカウントが作成されます。

サプライヤーがサプライヤー支払いアカウント情報を提出すると、自動的に Coupa に転送されてサプライヤー支払いアカウントレコードが作成されます。

SPA または Coupa Pay の設定方法については、Coupa FAQ ページの下部セクションをご覧ください。

Coupa でのバッチの作成

• 「Ready to Pay」ステータスの請求書のみがバッチの作成に使用できます。
• 「Actions」の下のスライダーボタンで請求書を Coupa Pay の支払いから削除できます （サプライヤーが Coupa Pay 用に選択されているが NetSuite から支払う必要がある場合は、支払い方法を ERP に切り替えます）。
• 「Pay from Account」（会社支払いアカウントまたは CPA）は勘定科目表に基づいて自動デフォルト設定されます。ドロップダウンを選択することで CPA を手動調整できます。
  • 「Pay to Account」（サプライヤー支払いアカウントまたは SPA）は請求書の Remit-To に基づいてデフォルト設定されます。

Coupa でのバッチの承認

• 支払いバッチをリリースする前に承認チェーンが生成されます。

Coupa 統合 - 支払いのトラブルシューティング

支払いの統合問題を特定する NetSuite エラーログは、毎週火曜日と金曜日に買掛金チームにメールで送信されます。メールは Finance Systems Admins から送信され、件名は Coupa2NS Pay Payments Integration Log です。添付ファイルをダウンロードし、Type = Error と Audit でフィルタリングします。Details フィールドをレビューして確認/修正が必要な支払い番号を見つけます。一般的なエラーとその修正方法については、こちらのファイルをご覧ください。Script 列で Coupa Invoice Payment Integration を検索してください。トラブルシューティングの支援が必要な場合は、#coupa_help Slack チャンネルでお問い合わせください。

NetSuite にエクスポートされていない支払いをリストする Coupa のビューもあります。Payments の下で View = Not Exported を選択します。

ただし、統合の問題に関する詳細は表示されません。詳細については NetSuite エラーログ（上記参照）をレビューする必要があります。

Coupa へのアクセス方法

Coupa は Okta 経由でアクセスできます。プラットフォームにアクセスするには：

1. Okta ホームページにログインします。
2. Coupa（Prod）ボタンをクリックします。
   • ログインしたユーザーで新しいタブが開きます。

職務上 Coupa で購入リクエストを提出する必要がある場合は、以下の手順に従ってください：

1. Individual_Bulk_Access_Request テンプレートを使用して Coupa のアクセスリクエストを開きます。
2. ステップ 2 の Justification for this access の質問で、以下を説明してください：
   • 購入する必要があるもの。
   • 購入の総コスト。
   • どのくらいの頻度で購入が必要か。
   • Coupa でいつ提出する必要があるか。
3. ラベル ~“FinSys - Coupa” と ~“FinSys::Service Desk” を追加します。

経費

詳細については、GitLab の経費ポリシーをご参照ください。

チームメンバーの経費精算 - Navan

Navan レポートの処理

1. Navan はレポートが「final approved」になると、自動的に同期して経費報告書を NetSuite に記録します。「final approved」とは、チームメンバーのマネージャーが承認し、買掛金アナリストまたは外部請負業者 Montgomery Pacific（Montpac）による監査レビューが完了したことを意味します。
2. 買掛金は、「final approved」になったすべてのレポートが NetSuite に正常に同期されているかどうかを確認するために日次チェックを行います。エラーが発生した場合、AP はレポートが NetSuite に同期されるまでエラーを解決します。

請求可能経費

• 顧客に請求可能な経費報告書がある場合は、Navan で「billable」フラグを確認し、Navan の「customer」フィールドに顧客名をタグ付けしてください。

Navan レポートの支払い

1. 米国の経費ポリシーに加入しているチームメンバーには、レポートが「final approved」になった後 1〜4 営業日以内に Navan を通じて自動的に払い戻しが行われます。
   • チームメンバーは Navan で銀行口座を設定する必要があります。
   • チームメンバーが払い戻しを受けると、Navan は経費レコードに支払いを自動同期してレポートを払い戻し済みとしてマークします。
   • これは NetSuite に反映されて請求書が全額支払い済みと表示されます。
2. PEO を通じて給与が支払われる国のチームメンバーも、毎月の同じ給与 PEO 支払いを通じて経費精算を受けます。
   • 注意： CXC、SafeGuard、Global PEO、Remote、および/または iiPay から直接払い戻しを受ける場合、払い戻しのタイミングが異なることがあります。
   • 支払いタイミングの詳細についてはこちらをご覧ください。
3. すべての非米国 GitLab 法人は、各給与プロバイダーを通じて、または通常の週次支払い実行で GitLab の買掛金（AP）部門から直接払い戻しを受けます。
   • 経費報告書はその週の火曜日の EOD までに「final approved」になっている必要があります。
   • その週の水曜日から金曜日に「final approved」になったレポートは翌週に払い戻しされます。
   • 従業員に払い戻しが行われると、AP は NetSuite のレコードに対して支払いを作成してレポートを支払い済みとして閉じます。
   • AP は給与プロバイダーへの確認または Tipalti へのバッチが完了した後、Navan で経費報告書を手動で「Reimbursed」にマークします。

Tipalti での Navan レポートの支払い

対象法人：GmbH、BV、PTY LTD、Ireland、IT BV、GK。

1. AP はチームメンバーにオンボーディング方法に関する指示を記載した Tipalti からの自動生成メールを送信します。
   • チームメンバーが Tipalti でオンボーディングを完了した後にのみ支払いが発行されます。支払先プロファイルは「Payable」として表示されます。
   • 2019-11-01 以降に採用されたチームメンバーは、採用時および/または最初の経費報告書の提出時にオンボーディングリクエストが送信されます。

経費精算プロセスの詳細についてはこちらをご覧ください。

買掛金アナリストパフォーマンス指標 - 経費

1. アクション平均日数 <= 3 営業日

   チームメンバーのマネージャーがレポートを承認してから、AP アナリストが支払いのための最終承認を行うか、または Navan で懸念事項についてチームメンバーに返答するまでの日数（支払いのための承認は払い戻し日ではありません）。これはカレンダー月単位で計算されます。目標は現在 3 営業日です。

2. 新チームメンバーを Navan に設定する時間 < 3 営業日

   チームメンバーの開始日から 3 営業日以内に新チームメンバーを Navan に設定します。

出張・経費ガイドライン

支出削減

支出を削減する際、私たちは（一時的に）裁量支出を削減するという安易な方法は取りません。 裁量支出には、出張、カンファレンス、ギフト、ボーナス、昇給、サミットなどの経費が含まれます。 これらの領域を削減すると、最も必要なメンバーの自発的な離職が増加するリスクがあります。

裁量支出は常に精査の対象であり、私たちは倹約的であり、すべての支出は私たちの目標に貢献する必要があります。しかし、支出削減の必要性に反応して削減すべきではありません。そうすることで平凡な会社と平凡なチームメンバーしか残りません。代わりに、目標に貢献していないポジションとコストを特定するという難しい作業をすべきです。短期的に多少の混乱を引き起こしても、ここにいる人々にとって素晴らしい職場であり続けることを確保するのに役立ちます。

非払い戻し経費

会社の代わりに商品やサービスを購入するには、まず署名権限マトリックスを参照して承認要件を確認してください。これには出張経費やその他の諸費用は含まれないことに注意してください。これらの経費は自己負担で支払い、その後 Navan で精算請求するか、独立した請負業者の場合は会社への請求書に含める必要があります（上記のガイドラインに従って）。

さらなる承認が不要な場合は、GitLab での購入プロセスのさらなる指示のために調達の「何を購入するか」ページに進んでください。これらの手順が完了したら、ベンダーに請求書を買掛金に送付させてください：[email protected]。最も重要なことは、購入リクエストを行うチームメンバーが請求書の最終レビューと承認に最終的な責任を負うことです。最終レビューと承認はベンダーへの誤った支払いを防ぐのに役立つ重要なプロセス管理です。すべての元の請求書と支払い領収書は買掛金に送付する必要があります。

経費タグの作成

特定のキャンペーン、プロジェクト、イベントの支出を追跡したい場合は、経費タグ（NetSuite ではクラスとも呼ばれます）を使用できます。経費タグ/クラスの設定をリクエストしたい場合は、このトラッカーを開いて、総勘定元帳（GL）チームがタグを作成するために必要な情報を入力してください。

• GL チームは毎日の終わりにタグを作成します。
• タグは NetSuite で作成され、Navan および Coupa と同期します。
• タグ作成プロセスの完了中に、購入要求を後で保存することができます。

NetSuite でのクラスの作成：

1. NetSuite で Setup-Company-Classes-New に移動します。
2. Name の下に経費タグの名前を追加します。
3. subsidiaries の下で GitLab Inc を選択し、「Include in Children」というボックスをチェックします。
4. 保存します。

Navan は毎日新しい「経費タグ」を自動同期しますが、Navan 管理者が手動で同期したい場合は次の手順に従ってください：

Navan での新規クラス/タグのインポート：

1. Admin ページに移動し、Policies タブをクリックします。
2. ポリシーを選択し、Connections サブタブを見つけます。NetSuite コネクターはこのページにあります。
3. NetSuite コネクターの Sync Now ボタンをクリックします。ページに同期ステータスを示すプロンプトが表示されます。
4. 同期プロセスが完了したら、Tags サブタブに移動します。
5. classifications の下で（前のステップで作成した NetSuite プロファイル）名前でタグを検索します。

法人クレジットカード

現在のポリシー/手順については、こちらのページをご覧ください。

コントリビュートコストとその他の主要経費

マーケティングキャンペーン経費

マーケティングハンドブックのキャンペーン経費ガイドラインをご参照ください。

GitLab コントリビュートコスト追跡

（以前は GitLab サミット）

会社のコントリビュートの経費追跡により、支出を分析し、イテレーションの機会を見つけ、その結果として後続のコントリビュートを改善できます。追跡を可能にするために、GitLab チームメンバーが Navan でコントリビュート関連の経費にタグ付けできる経費タグを作成します。これは各コントリビュートの発表前に行う必要があります。

• 特定のマーケティングキャンペーン、コントリビュート経費、および/または特別プロジェクトを追跡するために経費タグの下で経費を分類するには、Navan の「classifications」タグの下で行います。

有形固定資産

有形固定資産は、貸借対照表の長期資産または非流動資産のセクションです。以下はそのサブプロセスです：

取得と資本化

固定資産ポリシー

目的

このポリシーは、GitLab の財務諸表に記録される固定資産を決定するための最低コスト（資本化額）を確立します。

固定資産の定義

「固定資産」とは、12 ヵ月を超える経済的耐用年数を持ちかつ $5,000（USD）以上のコストで取得された（場合によっては生産された）財産の単位です。固定資産は財務報告目的で資本化および減価償却する必要があります。

資本化しきい値

GitLab は $5,000（USD） を資本化に必要な最小金額として設定しています。この金額を下回る費目は購入日に費用計上されます。主要コンポーネント資産（コンピューターラップトップなど）は例外です。

一括購入（単一の発注書で取得され、互いに適切な期間内（60 日未満）に受領され、個別には個別購入の資本化しきい値を下回る「同種」品目）の資本化しきい値は $50,000（USD）です。

減価償却/償却

方法論

すべての固定資産は取得日現在の取得原価で記録されます。これらの資産は定額法で減価償却され、減価償却期間の数は資産クラスによって決定されます。

• コンピューターおよび IT 機器： 私たちの目的では、コンピューターおよび IT 機器は主にコンピューター（ラップトップ）で構成され、標準耐用年数は 2 年です。この減価償却スケジュールはすべての法人に適用されます。
• 事務機器および家具＆備品： 事務機器および家具＆備品の標準耐用年数は 5 年です。この減価償却スケジュールはすべての法人に適用されます。

固定資産の請求書と購入領収書は最低 5 年間保管されます。

固定資産台帳と資産追跡

会社が支払った品目は会社の財産です。購入価格が $5,000 USD を超える資産または主要コンポーネント資産は、NetSuite 固定資産管理（FAM）モジュールを通じて記録・追跡されます。これには個別購入資産の詳細が含まれます。NetSuite FAM が提供する資産台帳レポートは、以下の情報を含む個別購入資産を提供します：

1. 購入の期間と日付
2. 資産コスト
3. 資産カテゴリ
4. 資産説明
5. 耐用年数
6. シリアル番号（利用可能な場合）
7. GL コーディング

情報が NetSuite FAM に記録されると減価償却スケジュールが作成され、NetSuite FAM は資産が完全に減価償却されるまで毎月仕訳を転記して資産の減価償却を記録します。資産は使用されなくなったと確認され処分が決定されるまで GitLab の貸借対照表に残ります。

資産の処分

資産は、退職時の従業員による購入（IT Ops によって承認された場合）または耐用年数前にアイテムが使用できなくなった場合に処分されます。

1. チームメンバーが会社から資産（ラップトップなど）を購入したい場合は、IT Ops と会計に Issue を通じてリクエストし、支払い金額を取得します。これは取得原価から累計減価償却額を差し引いたものから算出されます。資産が購入された場合、会計は資金を回収し、資産を処分するための適切な会計処理を行います。
2. 資産が耐用年数に達する前に使用できなくなった場合、従業員は IT Ops と会計に Issue を提出して通知する必要があります。IT Ops が評価し、アイテムが使用できなくなったと判断した場合、会計は NetSuite FAM から資産を処分するための適切な会計処理を行います。

IT Ops は資産を特定し、NetSuite FAM から資産を適切に処分するために会計に通知する必要があります。

会計ポリシー

記録から報告までのプロセスは、以下の会計ポリシーによって管理されています：

GITLAB INC. 関連当事者取引ポリシー

法務ページの関連当事者取引ポリシーをご参照ください。

会計チームの PTO ガイドライン

上場企業としてビジネス結果を推進するタイムリーな事実に基づいた情報を提供するという財務・会計のミッションを達成するためには、年間の特定の重要な時期にチームメンバーの参加が必要です。私たちの会計機能は、ビジネスの成長を支援し、上場会社としての義務を果たすための重要な時間ベースの成果物を提供します。これらの活動はチーム全体のサポートを必要とします。

チームメンバーはこれらの重要な時期以外にリフレッシュと充電のための休暇を優先すべきです。これらの正確な時期はチームによって異なりますが、一般的に四半期の最終週と次の四半期の最初の 2 週間はすべてのチームメンバーのサポートが必要です。あなたの役割に何が適用されるか不明な場合は、マネージャーに確認してください。これらの期間が週末（特に四半期の最終日）または祝日/家族と友人の日と重なる場合、チームメンバーはマネージャーと協力してその日をこの重要な四半期末期間外の日に変更することをお勧めします。チームメンバーがこの期間中に勤務できない場合は、可能な限り少なくとも 1 ヵ月前にマネージャーに通知して代替要員を手配できるようにしてください。適切な場合は、適用される管轄の要件に準拠しながら、祝日/週末のローテーションカバレッジ計画を作成します。

投資ポリシー

目的

このポリシーの目的は、余剰運転資金の投資に関する責任、権限、およびガイドラインを確立することです。余剰資金は、会社の運営要件を超え、運転資本や近期の財務債務に直ちに必要でない資金として定義されます。

範囲

このポリシーは会社およびすべての子会社に適用されます。この投資ポリシーは、会社の全体的な目標や現在の財務動向と一致しているかどうかを確認するために定期的に見直されます。

承認された証券会社

会社は以下の証券会社を使用することができます：

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

投資目標

会社の投資プログラムの基本的な目標は、優先順位の高い順に：

• 質の高い、分散されたポートフォリオの有価証券、投資信託、銀行預金に投資することによる元本の安全性と保全。
• 会社の予測されるキャッシュフロー要件と戦略的ニーズを満たすのに十分な投資の流動性。
• ここに記載された目標、保守的なリスク許容度、会社の現在の税務状況に一致する税引後の市場収益率の最大化。
• 満期制限
• 個々の証券の満期は 24 ヵ月を超えてはなりません。ポートフォリオの加重平均満期は 12 ヵ月を超えてはなりません。満期または実効満期は、定義上、流動性、安全性、資本保全と一致する定量化可能な価格で会社が投資を償還できるプット、公表済みコール、またはその他の構造的特徴を含みます。

適格投資

米国政府証券：

• 米国により直接発行されるか、元本と利息について米国政府が保証し、合衆国の完全な信用と信頼に支えられた市場性のある債務証券。
• 米国政府機関証券：
  • 米国の直接債務ではないが、政府の支援が関与し、政府機関または企業によって完全に保証された、政府支援企業、連邦機関、および特定の国際機関が発行する債務証券。以下を含みますが、これに限りません：
    • Federal Farm Credit Bank（FFCB）
    • Federal Home Loan Bank（FHLB）
    • Federal Home Loan Mortgage Corporation（FHLMC）
    • Federal National Mortgage Association（FNMA）

マネーマーケットファンド

マネーマーケットファンドは少なくとも 1 つの NRSRO によって AAA または同等の評価を受けている必要があります。

購入時の投資制限：

投資プロダクト（格付け、セクター集中、発行体集中）

1. 米国政府（AA+、セクター集中なし、Issue 集中なし）
2. エージェンシー（AA+、セクター集中 50%、発行体集中 10%）
3. マネーマーケットファンド - 米国政府/国債（AAA、セクター集中なし、発行体集中 50%）

前払費用ポリシー

目的

このポリシーは、GitLab の前払費用を監視および会計処理するために使用される方法論を説明します。

前払費用の定義

前払費用は、基礎となる商品・サービスの関連する恩恵を実現する前に、商品・サービスに対して現金が支出された場合に発生します。これらのトランザクションは商品・サービスが実現されるまで資産として記録され、その時点で費用が記録されます。前払費用を記録するための最低しきい値は $5,000 USD です。

前払費用の特定と記録

購入リクエストが会社承認ワークフローを通過すると、会計は前払費用が正確に記録されるように以下の手順を実施します：

1. 金額が $5,000 以上であること。$5,000 未満の前払費用は発生した期間に直ちに費用計上する必要があります。

2. 前払いが 12 ヵ月を超える期間のものであること（イベントのデポジットについては期間は除外されます）。

3. 単一の請求書の単一品目で $50,000 以上の場合、前払期間が会計四半期にまたがる場合に資本化できます。

4. マーケティング、コーポレートまたは他の部門のイベントに対して支払われたデポジットで $5,000 USD 未満のものは、イベントが実施されたかどうかに関わらず、請求書を受け取った日に費用として認識されます。

   $5,000 の水準は通常、請求書ごとまたは品目ごとに適用されます。ただし、（ベンダーあたりの総購入額などの）ケースバイケースのビジネス判断が必要な状況が存在することがあります。また、個別の前払いがそれぞれ水準を満たさなくても、全体として性質が類似しており、一括で購入されている場合は、前払いの合計金額を合算して前払いを記録すべきかどうかを決定する必要があります。例外は会社コントローラーまたは PAO が事前に承認する必要があります。

   償却は、月中旬の償却方法に基づく定額法で記録されます。サービスの最初の月が月の 1 日から 15 日に始まる場合、当月の全月分の償却が記録されます。サービスの最初の月が月の 16 日から末日に始まる場合、翌月の 1 日から償却が始まります。

   月中旬の償却方法は、月次償却額が $50,000 USD 以上の前払費用、または償却が 1 期間のみに及ぶ場合には適用されません。月次償却が $50,000 USD 以上の場合、最初の月の償却はサービスが提供された実際の日数に基づいて計算されます。

   未払前払費用：未払いの前払費用については、「prepaid not paid」の調整が対応する前払費用勘定と AP 手動調整勘定（GL 勘定 2001）に転記されます。前払費用は AP 補助元帳に負債が残っている場合は資産として扱われません。未払の前払費用の調整は最低四半期ごとに実施されます。 セキュリティデポジットや請負業者確保のためのデポジットなど、12 ヵ月を超えて保有されるデポジットは、Security & Other Deposits（GL 勘定 1620）に計上されます。

   クローバック条項付き前払ボーナスは、Prepaid Bonus w/Clawback（GL 勘定 1152）に記録され、月中旬の慣行を使用してボーナス契約条件に従って償却されます。

5. 最後に、シニア会計マネージャーが期間を締める前に財務諸表のレビューを行う際に、残高が最後に見直されます。

コントリビュート関連費用

チームメンバーの出張費用は発生した期間に費用計上されます。ホテル、施設、課外活動などのサードパーティベンダーに関連するコストは前払費用として記録され、イベントの時点で費用として認識されます。

未払負債ポリシー

目的

GitLab の未払いおよびその他の負債勘定に含まれる項目の特定と記録に関する明確なガイダンスを提供することです。月次発生プロセスの目的は、費用を適切な会計期間に配分し、費用と関連収益を対応させることです。毎月末の締め時に、発生プロセスにより、その月に関連するすべての費用が会社の財務諸表に正しく含まれるよう確保します。さらに、このポリシーは GitLab が月次発生の会計処理を経営目標および一般に認められた会計原則（GAAP）に準拠した方法で行うことを確保するための基準とガイドラインを確立します。このポリシーは GitLab およびすべての子会社に適用されます。

特定

すべての費用は、$5K USD 以上の費用について、発生した期間に記録することを要求します。発生プロセスは、負債がそれぞれの期間および/または四半期に正確に記録されるよう月次/四半期ベースで完了する必要があります。月末締め期限の業界基準を満たすために、財務・オペレーションチームは発生を支援するために必要な計算、情報、詳細、およびバックアップを営業日 -1（例：7 月 30 日金曜日 = 営業日 -1、8 月 2 日月曜日 = 営業日 1）に提供する責任があります。

以下の項目は必要に応じて月次で発生計上する必要があります（注意：このリストは網羅的ではありません）：

1. 買掛金：

   • 契約：リテーナー料を含む契約に基づく金額。これらの項目は請求可能になった時点で記録する必要があります。
   • 専門家費用：この負債には法律、税務、監査コンサルティングおよびその他の専門家費用が含まれます。
   • 法的不測事態：保留中または脅迫的な訴訟、および実際または見込みの和解。法的不測事態は GitLab の法務 VP（Commercial、IP & Compliance）の協力を得て決定する必要があります。

2. 賃金と報酬：

   • チーム賃金：従業員の賃金と独立した請負業者費用が含まれます。
   • コミッション：コミッション報酬の資格があるチームメンバーへのコミッション義務から生じる負債。
   • ボーナス：GitLab チームメンバーへのボーナス支払いに関連する負債。
   • 税金：GitLab チームに関連するすべての法定遵守のために必要な雇用税。

3. 上記に記載されていないその他の重要な GitLab の負債

タイミング

時間の経過とともに発生する義務は、方法論的かつ合理的な方法で会計期間全体にわたって記録されます。イベントが発生した時点で生じる義務は、イベントの時点で記録する必要があります。

未払負債の記録タイミングを決定する際に考慮される要因には以下が含まれます：

1. 商品またはサービスの受領による GitLab への所有権リスクの移転。
2. 費用は閉鎖対象の月中に発生している必要があります。つまり、プロダクトまたはサービスは費用として認定されるために月の最終日までに受領されている必要があります。
3. 費用が当初予算に組み込まれていても、会社がプロダクトまたはサービスを受領しない限り、発生計上の対象にはなりません。
4. 発生費用は翌月に取り消され、必要に応じて翌々月に再発生計上されます。
5. 商品またはサービスを受け取る前に支払いが必要な場合は、金額を前払費用として発生計上する必要があります。

手続き

財務チームは、勘定を月次で照合し、未払負債を支援する文書を保管する手続きを整備する責任があります。買掛金および未払負債は、額面価格に適用可能な調整を加減した金額で記録されます。ほとんどの場合、支払額はベンダーの請求書から決定できます。そうでない場合は、負債を記録する前に関連する文書に対して金額を確認する必要があります。実際の値が利用できない場合、記録値は入手可能な最善の見積もりに基づく必要があります。見積もりは現在の市場価格と経験/過去の実績に基づく必要があります。

1. 法律専門家費用：月次テンプレートが 1 日までにすべての法律事務所にメールで送信され、その月末（例：3 月 31 日現在のサービスとして 4 月 1 日までにメール送信）として未払い請求書と未請求サービスをすべて記入するよう依頼します。すべての法律事務所からの回答は 5 日までに法務 VP（Commercial、IP & Compliance）と共にまとめ・レビューされ、回答とレビューに基づいて発生計上されます。さらに、月次ミーティング中に法務 VP と潜在的な法的不測事態が議論され、損失が発生する可能性があり金額を合理的に見積もることができる場合に発生計上が記録されます。
2. 税務・監査専門家費用：同様にテンプレートのメールが税務・監査事務所に送信され、税務回答は税務ディレクターと共にまとめ・レビューされ、監査事務所の回答は 5 日までに会計・外部報告マネージャーと共にレビューされ、レビューに基づいて適切な発生計上が行われます。

シニア会計マネージャーは、買掛金が毎月締まった後の 1 〜 3 営業日以内に未払負債の全体的なレビューを行い、すべての費用が正確に記録されることを確保する責任があります。

購買から支払いまでを参照してください。

外貨換算ポリシー

概要

外貨換算は、外国法人の機能通貨（GitLab.com>Finance>Issues>#630 で決定・文書化されたもの）を報告法人の財務諸表通貨に変換するために使用される方法を説明します。外国法人の財務諸表を報告法人の通貨に換算する前に、外国法人の財務諸表は一般に認められた会計原則（GAAP）、具体的には財務会計基準審議会（FASB）基準書第 52 号に従って作成する必要があります。GitLab の財務諸表の報告通貨は USD です。米国外の子会社の機能通貨は現地通貨です。外貨換算の変化は、連結株主持分計算書に報告され、最終的に株主持分の下で連結貸借対照表に引き継がれるその他包括損益（損失）に記録されます。

為替レート

通貨換算プロセスで使用される為替レートは、3 つの主要な財務諸表コンポーネントによって異なります：

• 資産および負債： 期末における機能通貨と報告通貨の間の為替レート。
• 損益計算書： 提示された期間の平均為替レート。
• 株主持分： 株主持分に入力が行われる日の過去の為替レート。純利益の変化は、各期間の損益計算書の過去の為替レートに基づきます。

取引リスク対換算リスク

通貨取引リスク

通貨取引リスクは、外貨建ての会社取引から生じます。これらの取引は記録される前に法人機能通貨の同等額に換算する必要があります。支払いが行われたとき、または中間貸借対照表の日付で損益が認識されます。

通貨換算リスク

通貨換算リスクは、会社が外貨建ての資産および負債を所有していることから生じます。

累積換算調整

累積換算調整（CTA）は、時間の経過に伴う為替レートの差から生じる損益を要約する換算済み貸借対照表の包括利益セクションへの入力です。通貨の値は常に変動し、ある通貨が他の通貨に対してどのように評価されるかに影響します。CTA は、国際的なビジネス活動と外国市場へのエクスポージャーに関連する損益を把握する連結貸借対照表の行項目です。CTA の変化はその他包括損益（損失）に記録されます。CTA は、実際の業務損益と通貨換算プロセスから生じる損益を区別するのに役立つため、GAAP では必要とされています。CTA に関する報告基準の追加情報は、FASB Topic 830「Foreign Currency Matters」に記載されています。

CTA の記録 - 個別取引の為替レート損益は、ERP システムである NetSuite によって自動的に記録されます。ただし、連結財務諸表における通貨換算損益とその他一般的な損益を適切に区別するためには CTA の入力が必要です。この入力には、外国為替損益を生じさせる会社間取引の照合が含まれます。CTA は、財務諸表報告サイクルの一部として月次ベースで行われます。

勘定科目表ポリシー

範囲

このポリシーは、勘定科目表（COA）の基礎となる構造、責任、要件に関する GitLab のガイドラインを確立します。

目的

このポリシーは、GitLab が COA 上の新規、変更、または廃止のデータ要素のリクエストをどのように処理するかについての正式な責任と説明責任を確立します。コントローラーは財務会計と報告のすべての側面に責任を持ち、COA を管理します。COA のセグメント、階層、設定属性の新規または変更（廃止/非アクティブ化を含む）のすべてのリクエストは財務チームの承認が必要です。

COA の変更

新規または変更された勘定のすべてのリクエストは、財務 Issue トラッカーを通じたリクエストにより、会計マネージャーへのレビューと承認のために提出する必要があります。

COA に関連する他のステークホルダーも、特定のビジネス上の決定または財務システムの設定に影響を与える可能性があります。コントローラーと会計マネージャーは、適切な場合に、関連する手続きとプロセスに選択されたステークホルダーを含めます。潜在的なステークホルダーには以下が含まれますが、これに限りません：

• 財務計画＆分析
• データ＆アナリティクス
• 財務システム内で共有機能を持つその他の部門

このポリシーの対象となる総勘定元帳属性は、以下を含むがこれに限らない要因に基づいてコントローラーによって定義されます：

• 勘定構造の一貫性の作成と維持
• 標準的な会計ポリシーと実践
• 規制遵守の要件と報告ニーズ
• 財務および業務報告のニーズと要件
• 外部の会計と財務報告の要件

COA の修正が承認されると、会計マネージャーは Issue を更新して閉じることで、必要な変更が実施されることを確保します。

管理

COA は NetSuite で維持されています。COA への変更はコントローラーおよび/または会計マネージャーのみが行うことができます。

勘定照合ポリシー

範囲

このポリシーは GitLab Inc.（「GitLab」または「会社」）およびそのすべての子会社に適用されます。

目的

会社のポリシーおよび US 一般に認められた会計原則（「GAAP」）に従って、一貫した基準で貸借対照表勘定照合の評価、準備、レビューのガイドラインを確立します。

ポリシー

勘定照合は、評価されたリスク評価（以下のリスク評価の評価を参照）に基づき、自然勘定レベルでのアクティブな各貸借対照表勘定について月次または四半期ごとに準備・レビューされます。勘定照合は USD で連結または各法人の機能通貨でそれぞれ準備されます。

月末締め時に、会計マネージャーは FloQast（勘定照合ツール）を使用して、各貸借対照表勘定またはグループの勘定をそれぞれの準備者とレビュアーに割り当てます。割り当ては一度設定され、翌会計期間に引き継がれます。会計マネージャーは必要に応じて割り当てを変更します。職務分離を確保するため、準備者とレビュアーは同一人物ではなりません。

NetSuite の残高は各期末に FloQast に自動同期されるため、準備者は割り当てられた勘定の NetSuite 期末残高に基づいて照合を作成できます。

準備者は以下を確保します：

• すべての活動をレビューして活動が適切に記録されているか確認する。
• 照合項目を特定する。
• 必要に応じてサポートドキュメントをアップロードおよび/またはスケジュールを追加する。
• FloQast で照合にサインオフする。

レビュアーは以下を確保します：

• 勘定照合がこのポリシーに準拠して作成されていることを確認する。
• 勘定照合が完全、正確、かつ適切であることを確認する。
• FloQast で勘定照合にサインオフし、照合のステータスをレビュー済み/承認済みステータスに更新する。

FloQast は以下が満たされた場合に自動的に照合にサインオフします：

• 残高がゼロ

レビュー、承認、または自動サインオフ後に残高が変更された場合、FloQast によって照合が自動的に未照合になり、準備者とレビュアーは上記の手順を再度実施する必要があります。

リスク評価の評価

年に一度、Q4 の初めに、コントローラーおよび/または CFO が各アクティブな貸借対照表勘定をレビューし、高、中、低で評価します。各勘定のリスクレベルは、定量的な価値（重要性の判断のため）と以下の定性的要因の両方に基づいて評価されます：

• 必要な判断のレベル：必要な判断のレベルが高まるほどリスクが増加する
• ルーティン/非ルーティン取引：活動を記録するために必要な非ルーティン/非標準プロセスの量が増えるほどリスクが増加する
• 問題の履歴：監査関連の調整、質問、修正申告の数が増えるほどリスクが増加する
• 複雑さ：貸借対照表に影響を与えるビジネス/システムの変更、新しい公表、新しい複雑な計算によりリスクが増加する

高リスク勘定は準備者が月次で照合し（税務および株主持分関連勘定は四半期ごとに照合する例外を除いて）、会計マネージャー以上による第 1 レベルのレビューと CFO または PAO による第 2 レベルのレビューが必要です。

中リスク勘定は準備者が月次で照合し、会計マネージャー以上による第 1 レベルのレビューが必要です。

低リスク勘定は準備者が月次または四半期ごとに照合し、会計マネージャー以上による第 1 レベルのレビューが必要です。

活動がなく/または勘定残高がゼロの場合、照合は BlackLine によって自動認証されます。

各照合がレビュー/承認されると、勘定照合は BlackLine でロックされ、その期間に関するそれ以上の変更は行えません。

完全性チェック

期間が正式に締まると、シニア会計マネージャーは次の期間に移行する前に、すべての照合が承認済み、レビュー済み、または自動認証済みの状態にあることを確認します。

ページのソースコードを見る - ページの編集 - please contribute.