--- title: "MLMシステムとは？ネットワークビジネスの報酬計算の仕組みと特商法対応の要件" url: "https://www.issoh.co.jp/column/details/8678/" published: 2025-09-03 updated: 2026-10-07 categories: ["業務システム"] publisher: "株式会社一創" --- # MLMシステムとは？ネットワークビジネスの報酬計算の仕組みと特商法対応の要件 MLMシステムは、ネットワークビジネス（MLM）の会員・組織図・注文・報酬計算をまとめて扱う業務システムです。一般の販売管理システムと違い、会員どうしの紹介関係をツリーで持ち、1件の注文を上位の何人もの報酬に配ります。 この記事では、ユニレベルとバイナリーを中心に報酬の仕組みを図と計算例で説明し、組織ツリーのテーブル設計と報酬計算をPostgreSQL 18.6で実行したSQLで示します。後半では、特定商取引法の連鎖販売取引規制と、2026年10月1日に80%から70%へ下がったインボイスの経過措置を、システムが持つべき機能に置き換えて整理します。最後に、パッケージを使うか個別に開発するかの判断基準を扱います。 ## まとめ：MLMシステムを選ぶ・作るときの要点 - **守備範囲**：会員管理・組織図・受注とオートシップ・報酬計算・入金と支払い・会員向け画面。販売管理との差は組織ツリーと多段の報酬計算 - **報酬の仕組み**：ユニレベルは段数ごとの率、バイナリーは左右2系列のうち少ない側の実績が基準。どのプランも「ツリー・購入実績・ランク」の3つから計算する - **設計の要**：紹介者と配置上の親を別の列で持つ。1列にするとスピルオーバーのあるバイナリーで紹介系列が消える - **法令対応**：概要書面・契約書面の交付記録（電子交付は承諾の記録が必須）、契約書面受領から20日のクーリング・オフ、期間の制限がない中途解約と、入会1年未満・引渡しから90日以内などの条件つきの商品返品を、日付計算と報酬の取消しまで含めて実装する - **税務**：会員報酬を課税仕入れとして扱う場合、インボイス登録のない会員への支払いは、2026年10月1日から2028年9月30日まで仕入税額の70%を控除する経過措置の対象（帳簿の記載などの要件あり）。会員ごとの登録番号の管理が要る - **判断基準**：標準的なプランで会員の伸びが読めないうちはASP型、独自プランを頻繁に変える・既存ECと深く連携するなら個別開発 ## MLMシステムの守備範囲と販売管理システムとの違い MLMシステムは、ネットワークビジネス（MLM＝マルチレベルマーケティング）の会員登録・組織管理・受注・報酬計算・支払いを1つのデータベースで回す業務システムです。「ネットワークビジネス管理ソフト」「MLM業務管理システム」「ボーナス計算ソフト」と呼び方は違っても、中身はほぼ同じです。 一般的な販売管理システムとの違いは、**会員どうしのつながり（組織ツリー）を持ち、その形に沿って報酬を配る**点にあります。ここでは販売管理を受注・売上・入金管理中心の構成として比較します。MLMでは、これらに加えて1件の注文を複数階層の報酬へ配分する処理が必要です。国内のMLMパッケージの機能一覧を見ても、会員管理・売上管理・オートシップ（定期購入）・ボーナス計算・入金処理・明細発行が基本機能として並びます。 | 機能 | 販売管理システム | MLMシステム | | ------- | ---------- | --------------- | | 顧客・会員台帳 | 取引先単位 | 会員単位＋紹介者・配置上の親 | | 組織図 | なし | 紹介系列と配置系列のツリー表示 | | 受注 | 都度注文 | 都度注文＋オートシップ | | 報酬 | 営業手数料程度 | 報酬プランに沿った多段計算 | | ランク | なし | 実績による昇格・降格の判定 | | 法定書面 | 通販なら最終確認画面 | 概要書面・契約書面と交付記録 | | 会員向け画面 | マイページ程度 | 自分の組織図・実績・報酬明細 | この差のうち、システムの出来を分けるのは「組織ツリー」と「報酬計算」です。会員画面やメール配信は汎用の会員サイトの部品で足ります。報酬計算を表計算ソフトで行う場合は、想定会員数と注文件数で締め処理を試し、処理時間や返品調整の手作業が運用上の期限を超えるなら移行を検討します。 ## ネットワークビジネスの報酬の仕組みと主な報酬プラン ネットワークビジネスの報酬は、自分が紹介した会員とその下に連なる会員（ダウンライン）の購入実績をもとに計算します。実績は金額ではなく、商品ごとに決めたポイントで数える会社が多くあります。**PV**と略されることが多いものの、「ポイントバリュー」「パーソナルボリューム」など正式名称と定義は会社ごとに違うため、自社の報酬規定の定義に合わせます。どの範囲の実績に、どの率を掛けるかを定めたものが報酬プラン（コンペンセーションプラン）で、会社ごとに違います。 用語を先に揃えておきます。自分より上の系列を**アップライン**、下の系列を**ダウンライン**と呼びます。自分を紹介した人が**スポンサー（紹介者）**で、ツリー上で自分の直上に置かれた人（配置上の親）とは一致しないことがあります。 ### ユニレベル：段数ごとの率で払う仕組み ユニレベルは、紹介した人をすべて自分の直下（1段目）に並べ、段数ごとに決めた率を掛けるプランです。直下の人数に上限がないので、組織図は横に広がります。「1段目5%・2段目3%・3段目2%」のように深い段ほど率を下げ、支払う段数に上限を設けるのが基本形です。 システム上の論点は**コンプレッション（圧縮）**です。実績条件を満たさない会員を飛ばして段数を数え直す規定があると、同じツリーでも報酬の届く範囲が変わります。仕様書に「誰を飛ばし、何段先まで詰めるか」を書き切らないと、計算結果を検証できません。 ### バイナリー：左右2系列の少ない側で払う仕組み バイナリーは、1人の下に左右2つの枠だけを持たせるプランです。左系列と右系列の実績を合計し、**少ない側（弱い系列）の実績**を基準に報酬を計算します。片方だけ伸ばしても報酬が増えないため、左右の両方を育てる動機が生まれます。 直下が2枠しかないので、3人目以降に紹介した会員は空いている下の枠に置かれます。これが**スピルオーバー**で、紹介者（スポンサー）と配置上の親が別人になる原因です。多い側の実績を翌月へ繰り越すか切り捨てるか、1回あたりの支払上限をいくらにするかもプランごとに違うため、システムには「繰越残高」を会員ごとに持たせます。 ``` A ┌──┴──┐ B(左) C(右) ┌─┴─┐ │ D(左) E(右) F(左) ← FはAの紹介だがCの下に配置 │ G(左) 左系列 = B,D,E,G 右系列 = C,F ``` ### マトリックス・ブレイクアウェイ・ステアステップの違い ほかの代表的なプランは次のとおりです。実際には複数のプランを組み合わせたハイブリッド型も多く、国内のMLMパッケージにも、対応プランから選んで組み合わせる構成の製品があります。 | プラン | 組織の形 | 計算の基準 | システム上の論点 | | -------- | -------------- | ----------- | ----------- | | ユニレベル | 横に無制限 | 段数ごとの率 | コンプレッション | | バイナリー | 左右2枠 | 少ない側の実績 | 繰越残高と上限 | | マトリックス | 幅×深さが固定（3×7など） | 枠内の実績 | 満杯時の自動配置 | | ステアステップ | 横に無制限 | 自分の実績ランクの率 | 上位との率の差額 | | ブレイクアウェイ | ステアステップの派生 | 独立したグループの実績 | 独立後の実績の切り分け | どのプランでも、計算に要るデータは「誰が誰の下にいるか」「いつ何PV買ったか」「その時点のランク」の3つです。この3つを基礎データとし、プランごとに資格の有効状態、繰越残高、支払上限、適用する規約の版などを追加して計算します。 ## 報酬計算をSQLで実装する例（PostgreSQL 18.6で実行） 組織ツリーの扱い方を具体的に示すため、ユニレベルとバイナリーの計算をPostgreSQLの再帰クエリで書きました。以下はすべてPostgreSQL 18.6で実行し、出力をそのまま載せています。率やPVは説明用の値です。 ### 組織ツリーのテーブル設計：紹介者と配置上の親の分離 最初の設計判断は、紹介者（`sponsor_id`）と配置上の親（`parent_id`）を**別の列**にすることです。1列にまとめると、スピルオーバーのあるバイナリーで「誰の紹介で入ったか」が消え、紹介ボーナスやユニレベル部分を計算できなくなります。左右の枠は `UNIQUE (parent_id, leg)` で1人ずつに制限します。UNIQUE制約はNULL同士を重複とみなさないため、親がいる会員には `leg` を必須にするCHECK制約も加えます。これがないと、同じ親の下に枠なしの会員を何人でも登録できてしまいます（`leg` がNULLの行を入れると、このCHECKで弾かれることを確認済みです）。 ``` CREATE TABLE members ( id int PRIMARY KEY, name text NOT NULL, sponsor_id int REFERENCES members(id), -- 紹介者（ユニレベルの親） parent_id int REFERENCES members(id), -- 配置上の親（バイナリーの親） leg char(1) CHECK (leg IN ('L','R')), CHECK ((parent_id IS NULL AND leg IS NULL) OR (parent_id IS NOT NULL AND leg IS NOT NULL)), UNIQUE (parent_id, leg) -- 1つの親の左右に1人ずつ ); CREATE TABLE sales ( member_id int REFERENCES members(id), sold_on date, pv int NOT NULL ); INSERT INTO members VALUES (1,'A',NULL,NULL,NULL), (2,'B',1,1,'L'),(3,'C',1,1,'R'), (4,'D',2,2,'L'),(5,'E',2,2,'R'), (6,'F',1,3,'L'), (7,'G',4,4,'L'); INSERT INTO sales VALUES (2,'2026-09-05',100),(3,'2026-09-10',300),(4,'2026-09-12',200), (5,'2026-09-20',150),(6,'2026-09-25',120),(7,'2026-09-28',80), (2,'2026-08-30',999); ``` FはAの紹介ですが、Aの左右が埋まっているためCの左に置いています。最後の999PVは8月分で、9月の締めには含めません。 ### ダウンラインの取得とユニレベル報酬 ダウンラインは `WITH RECURSIVE` で紹介者をたどって取ります。段数を列に持たせ、支払う最大段数で再帰を止めます。 ``` WITH RECURSIVE down AS ( SELECT id, 1 AS lvl FROM members WHERE sponsor_id = 1 UNION ALL SELECT m.id, d.lvl + 1 FROM members m JOIN down d ON m.sponsor_id = d.id WHERE d.lvl < 3 ), rate(lvl, r) AS (VALUES (1, 0.05), (2, 0.03), (3, 0.02)) SELECT d.lvl, sum(s.pv) AS pv, sum(s.pv * r.r) AS bonus FROM down d JOIN sales s ON s.member_id = d.id AND s.sold_on >= '2026-09-01' AND s.sold_on < '2026-10-01' JOIN rate r USING (lvl) GROUP BY ROLLUP (d.lvl) ORDER BY d.lvl; lvl | pv | bonus -----+-----+------- 1 | 520 | 26.00 2 | 350 | 10.50 3 | 80 | 1.60 | 950 | 38.10 ``` 1段目はB・C・F（紹介者がA）、2段目はD・E、3段目はGです。Fは配置上はCの下でも、紹介者で数えるユニレベルではAの1段目に入ります。2つの列を分けた意味がここに出ます。 ### バイナリーの左右集計と繰越の計算 バイナリーは配置上の親（`parent_id`）をたどり、Aの直下で左右どちらの系列に属するかを引き継ぎます。 ``` WITH RECURSIVE tree AS ( SELECT id, leg AS side FROM members WHERE parent_id = 1 UNION ALL SELECT m.id, t.side FROM members m JOIN tree t ON m.parent_id = t.id ), vol AS ( SELECT coalesce(sum(s.pv) FILTER (WHERE t.side = 'L'), 0) AS left_pv, coalesce(sum(s.pv) FILTER (WHERE t.side = 'R'), 0) AS right_pv FROM tree t JOIN sales s ON s.member_id = t.id AND s.sold_on >= '2026-09-01' AND s.sold_on < '2026-10-01' ) SELECT left_pv, right_pv, least(left_pv, right_pv) AS paid_pv, abs(left_pv - right_pv) AS carry_over FROM vol; left_pv | right_pv | paid_pv | carry_over ---------+----------+---------+------------ 530 | 420 | 420 | 110 ``` `coalesce` は省略できません。片側の系列に当月の売上が1件もないと `sum` はNULLを返し、PostgreSQLの `least` はNULLを無視するため、支払基準が0ではなく多い側の値になります。右系列の売上を消して実行すると、`coalesce` ありでは「530 | 0 | 0 | 530」と正しく0になります。 左530PV・右420PVなので、報酬の基準は少ない側の420PVです。差の110PVを繰り越す規定なら、左系列の繰越残高として翌月の計算に足します。本番では前月までの繰越残高を別テーブルに持ち、締めのたびに更新します。 ### 紹介関係の循環検出：PostgreSQLのCYCLE句 管理画面で紹介者を付け替えられるシステムでは、誤操作で循環（AがGの下に入り、GはAの下にいる）が起きます。循環したツリーで上位をたどる再帰クエリは止まりません。PostgreSQL 14以降の `CYCLE` 句を使うと、たどった経路を記録して循環を検出できます。 ``` -- 誤操作：Aの紹介者をAから3段下のGにしてしまった UPDATE members SET sponsor_id = 7 WHERE id = 1; WITH RECURSIVE up AS ( SELECT id, sponsor_id FROM members WHERE id = 7 UNION ALL SELECT m.id, m.sponsor_id FROM members m JOIN up u ON m.id = u.sponsor_id ) CYCLE id SET is_cycle USING path SELECT id, sponsor_id, is_cycle, path FROM up; id | sponsor_id | is_cycle | path ----+------------+----------+----------------------- 7 | 4 | f | {(7)} 4 | 2 | f | {(7),(4)} 2 | 1 | f | {(7),(4),(2)} 1 | 7 | f | {(7),(4),(2),(1)} 7 | 4 | t | {(7),(4),(2),(1),(7)} ``` 運用では、紹介者を変更する前に「新しい紹介者の上位系列に本人が含まれていないか」をこのクエリで確かめ、含まれていれば更新を拒否します。外部キーやCHECK制約だけでは循環を防げません。 会員数が数十万規模になると、締めのたびに全員分の再帰をたどる方式は時間がかかります。その場合は祖先と子孫の組を全件持つ閉包テーブル（クロージャテーブル）や、経路を文字列で持つ方式に切り替えます。どちらを採るかは、組織の付け替えがどれだけ頻繁に起きるかで決まります。テーブル間の関係の書き方は[ER図の書き方](/tech/details/13484/)で解説しています。 ## 特定商取引法の連鎖販売取引規制とシステム要件 ネットワークビジネスは、特定商取引法33条の「連鎖販売取引」に当たります。商品の再販売などをする人を「特定利益（紹介や販売で得られる利益）」を得られると誘い、「特定負担（商品の購入や入会金など）」を伴う契約を結ぶ取引です。規制の全体像は[特定商取引法の7類型と表示義務の解説](/column/details/17346/)にまとめています。ここでは、MLMシステムの機能に直結する条文に絞ります。 ### 概要書面・契約書面の交付と電子交付の承諾記録 特定商取引法37条は、店舗によらずに事業を行う個人と契約するとき、契約前に連鎖販売業の概要を記載した**概要書面**を、契約後は遅滞なく**契約書面**を交付するよう義務づけています。2023年6月1日からは、相手方の承諾を得れば書面の代わりに電磁的方法（PDFの送付やWeb上での提供など）で渡せるようになりました（37条3項）。 電子交付にはシステム側で残すべき記録が多くあります。特定商取引法施行令21条により、事業者は使う電磁的方法の種類と内容を先に示したうえで、書面などで承諾を得る必要があります。施行規則81〜86条は、提供方法、事前に示す事項、相手が端末で書面を見られるかの確認、承諾の取り方、受領・閲覧の確認などを定めています。システムには少なくとも次を持たせます。 - 会員ごとの概要書面・契約書面の版番号と交付日時 - 電子交付の承諾日時・承諾の方法・事前に示した説明の版 - 書面ファイルの到達・閲覧の記録（クーリング・オフ期間の起算に関わる） オンライン登録フォームで入会を受け付ける設計なら、承諾の取得と書面の提供を登録の画面遷移に組み込み、承諾がない会員には紙の書面を発送する分岐を用意します。 ### クーリング・オフ20日と中途解約・返品の日付計算 連鎖販売取引のクーリング・オフ期間は、契約書面を受け取った日から**20日**です（40条）。特定負担が再販売用の商品の購入で、最初の商品の引渡しが書面の受領より後なら、その引渡しの日が起算日になります。システムは会員ごとに契約書面の受領日と最初の引渡日を持ち、遅いほうを起算日（1日目）として20日目を期限にします。解除は通知を発した時に効力が生じる（40条2項）ので、判定には届いた日でなく発信日を使います。勧誘者が解除について事実と違うことを告げたり威迫したりして解除を妨げた場合は、解除できる旨を記載した書面を改めて受け取った日から20日になるため、こうした案件は通常の期限計算から外して扱います。 20日を過ぎた後も、会員は将来に向かって契約を解除（中途解約）できます（40条の2第1項）。さらに、入会から1年を経過していない会員が中途解約した場合は、商品の売買契約も解除できます（40条の2第2項）。除外されるのは次表の商品と、同項4号の政令で定める場合です。販売者が会員に使用・消費させた商品は、使用・消費済みでも返品の対象から外せません。 | 返品できない商品 | システムで持つデータ | | -------------- | ------------- | | 引渡しから90日を過ぎた商品 | 注文明細ごとの引渡日 | | 再販売した商品 | 小売の記録（再販売の有無） | | 使用・消費した商品（原則） | 返品時の検品結果 | 返品に伴って事業者が請求できる損害賠償などには上限があります。商品が返還された場合と引渡し前の場合は販売価格の10分の1と法定利率による遅延損害金まで、返還されない場合は販売価格に相当する額と同じ遅延損害金までです（40条の2第4項）。返金額の計算画面には、この上限を超える手数料を設定できないようにしておきます。 見落とされやすいのが**報酬の取消し**です。クーリング・オフや返品で売上が取り消されると、その売上をもとに上位会員へ払った報酬も計算し直す必要があります。締め済みの月の売上が後から消える前提で、「どの売上がどの報酬の根拠になったか」を明細単位で追える構造にしないと、返品のたびに手作業で差額を探すことになります。 ### 広告表示と勧誘の禁止行為に関わるデータ 特定商取引法35条は、連鎖販売取引の広告に、商品・役務の種類、特定負担、特定利益を広告するならその計算方法、統括者の氏名・住所・電話番号などの表示を求めています。会員向けに報酬プランの説明ページや資料を配る機能を持たせるなら、特定利益の計算方法の記載が欠けないよう、資料の版を管理画面で一元管理するのが安全です。 34条は、重要事項を故意に告げない・事実と違うことを告げる行為、威迫して困らせる行為、目的を隠して人目のない場所で勧誘する行為を禁じています。システムで防ぎきれる性質のものではありませんが、苦情や問い合わせを会員と紹介者に紐づけて記録しておくと、特定の系列に勧誘トラブルが集中していないかを確認できます。 ## 報酬支払いの税務：インボイス経過措置と源泉徴収 会員への報酬支払いには、消費税と所得税の両面で会員ごとの属性管理が要ります。 消費税では、会員への報酬を課税仕入れとして扱う場合、その会員がインボイス発行事業者かどうかで控除できる額が変わります。免税事業者など登録のない相手からの課税仕入れは、経過措置で一定割合だけ控除できます。令和8年度税制改正でこの措置が延長され、割合は次のとおりになりました（国税庁 インボイス特設サイト）。 | 期間 | 控除できる割合 | | --------------------- | ------- | | 2023年10月1日〜2026年9月30日 | 80% | | 2026年10月1日〜2028年9月30日 | 70% | | 2028年10月1日〜2030年9月30日 | 50% | | 2030年10月1日〜2031年9月30日 | 30% | | 2031年10月1日以後 | 0% | あわせて、登録のない1つの相手からの課税仕入れが年（事業年度）で税込1億円を超える場合、超えた部分には7・5・3割の控除を適用できなくなりました（改正前は10億円。2026年10月1日以後に開始する課税期間から適用）。MLMシステムでは、会員マスタに登録番号と登録日を持たせ、支払明細を「登録あり」「登録なし」で分けて集計できるようにしておきます。割合が段階的に変わるため、率は日付つきの設定値として持ち、コードに直書きしないことが要点です。 所得税では、個人の会員に払う報酬が源泉徴収の対象になるかを、「ボーナス」「紹介料」といった名称ではなく支払いの実質で判定します（所得税法204条1項）。たとえば外交員等に支払う報酬・料金に当たる場合、支払時に源泉徴収が必要で、居住者に対する税額は、月の報酬から12万円を控除した残額の10.21%です。同月に給与等も支払う場合は、12万円からその月の給与等の額を引いた残額を控除し、算出した税額の1円未満は切り捨てます（国税庁タックスアンサー No.2804）。個別の報酬については名称だけでは税務上の区分を確定できないため、自社の報酬がどの区分に当たるかは税理士と確定させ、その結果を会員区分ごとの源泉徴収の要否としてシステムの設定に落とします。 ## パッケージ・ASP型か個別開発かの判断基準 国内製品の例には、ASP型のリジョンや、パナシアのMLM基幹システム「ProFlow」があります。リジョンはバイナリー・ユニレベル・マトリックス・ブレイクアウェイ・パスアップなどの報酬プランに対応し、ASP版で最短2週間の導入をうたっています。ProFlowはAWS上のクラウド構成で、組織図や入金の自動消込みを標準機能に挙げています。どちらも公式サイトに価格の掲載はなく、問い合わせ制です。 次表を初期判断の目安とし、候補製品の設定変更範囲、連携API、データ出力範囲、想定件数での締め処理時間を確認して選びます。 | 条件 | ASP型・パッケージ向き | 個別開発向き | | -------- | ------------ | -------------- | | 報酬プラン | 標準プランの組み合わせ | 独自の条件・計算が多い | | プラン改定 | 年1回程度 | キャンペーンごとに変える | | 既存システム | 新規立ち上げ | 自社EC・基幹と深く連携 | | 会員数の見通し | まだ読めない | 大規模で締め時間が問題 | | データの持ち出し | CSV出力で足りる | 報酬根拠まで自社で保持したい | 新規にMLM事業を始めるなら、まずASP型で始めるのが妥当です。報酬プランは事業を回しながら変わるもので、最初から個別開発すると、変わる前の仕様に費用をかけることになります。一方、次の状態に当てはまるなら個別開発や移行を検討すべきです。 - 報酬の一部を毎月表計算ソフトで手計算して補っている（パッケージがプランに対応できていない） - 返品やクーリング・オフのたびに、報酬の取消し額を担当者が探している - 締め処理に時間がかかり、報酬明細の公開が遅れている 個別開発で失敗しやすいのは、報酬プランの仕様を「説明会の資料」のまま発注するケースです。資料には「1段目5%」とは書いてあっても、圧縮の有無、ランクの判定日、繰越の扱い、返品時の取消しは書いてありません。発注前に、架空の10〜20人のツリーと購入実績を作り、月ごとの正解の報酬額を表で用意してください。その表がそのまま受け入れテストになります。会員の権限・ランクの設計は[ロイヤルティプログラムのランク設計と会員基盤の要件](/column/details/18131/)、会員向け画面の構築方式は[会員サイトの仕組みと構築方式の決め方](/column/details/18124/)が参考になります。代理店網の管理が主目的で多段の報酬が要らないなら、MLMシステムではなく[PRMツール](/column/details/4804/)の領域です。オートシップの継続課金は[サブスクリプション課金の実装](/tech/details/15728/)と同じ論点を持ちます。 ## MLMシステムと報酬計算のよくある質問 ### ダウンラインとは何ですか？ ネットワークビジネスで、自分より下に連なる会員の系列のことです。自分が紹介した会員と、その会員がさらに紹介した会員などが含まれます。逆に自分より上の系列はアップラインと呼びます。 ### ネットワークビジネスの報酬はどういう仕組みで決まりますか？ 自分のダウンラインの購入実績（PVなどのポイント）に、報酬プランで決めた率を掛けて計算します。ユニレベルなら段数ごとの率、バイナリーなら左右2系列のうち少ない側の実績が基準です。プランは会社ごとに異なります。 ### バイナリーの組織図はどう見ればよいですか？ 各会員の下に左右2つの枠があり、左の系列と右の系列の実績を比べて見ます。直下の2枠が埋まると、新しく紹介した会員はより下の空き枠に置かれる（スピルオーバー）ため、紹介者と配置上の親が別人になることがあります。 ### MLMシステムは表計算ソフトで代用できますか？ 会員が数十人で、ユニレベルの段数も浅いうちは計算できます。ただし、スピルオーバー、繰越、返品時の報酬の取消し、法定書面の交付記録まで表計算で管理すると、締めのたびに手作業の照合が残ります。会員が増える前に移行するほうが、データの移行も小さく済みます。 ### MLMシステムにクーリング・オフ機能は必要ですか？ 必要です。連鎖販売取引のクーリング・オフ期間は契約書面の受領日（再販売用の商品なら、受領より後の最初の引渡日）から20日で、起算日の計算に書面受領日と引渡日の両方が要ります。解除に伴って売上と上位会員の報酬を取り消す処理も、システム側で持つべき機能です。 ## 関連記事 - [特定商取引法とは？7類型の規制と通信販売の表示義務をEC実装要件で解説](/column/details/17346/) - [ロイヤルティプログラムとは？4つの種類とランク設計、法務の条件と会員・ポイント基盤の要件【2026年版】](/column/details/18131/) - [会員サイトとは？仕組み・公開方式と会員管理システムとの違い、構築方式の決め方](/column/details/18124/) - [PRMツールとは？主要機能とCRM・SFAの違い・選び方・代表ツールを比較](/column/details/4804/) - [ER図とは？書き方・エンティティやリレーション・カーディナリティを実装目線で解説](/tech/details/13484/) --- 出典: [MLMシステムとは？ネットワークビジネスの報酬計算の仕組みと特商法対応の要件]()（株式会社一創）