この記事は、当社のロイヤリティ管理完全ガイドの一部です。
独立した出版社を経営している場合、ロイヤリティプロセスがスプレッドシート内に存在する可能性が高いです。最初は数個のタブを持つ単一のワークブックから始まったかもしれません。時間とともに、数式の絡み合い、コピーされたシート、そして1人だけが真に理解している色分けされたセルのもつれに成長しました。それは機能しますが、機能しなくなる日が来ます。
問題はExcelが悪いソフトウェアであることではありません。Excelは設計されたことに関しては並外れています。ただし、ロイヤリティ管理はそれが設計されるために意図されていないものであり、「技術的に可能」と「規模での信頼性」の間のギャップが出版社を傷つけるのです。
壊れた数式と静かなエラー
スプレッドシートの数式は静かに壊れます。セル参照内に誤配置されたドル記号、SUM範囲の途中に挿入された行、ソート後にシフトした列を指すVLOOKUP。これらのどれも警告を生成しません。セル内の数値は完全に妥当に見えます。著者が明細書に異議を唱えるか、さらに悪いことに、会計士が監査中にそれを見つけるまで、間違いを発見しません。
European Spreadsheet Risks Interest Groupからの調査では、研究された大規模なスプレッドシートのほぼすべてにエラーが発見されています。タイトル、形式、流通業者全体の層状の計算を備えたロイヤリティワークブックは、これらのエラーが繁栄するスプレッドシートの種類そのものです。
バージョンの競合と「どのファイルが正しいのか？」という問題
ロイヤリティ処理は単一の操作で起こることはめったにありません。売上ファイルをダウンロードし、ワークブックにデータを貼り付け、計算を実行し、レビューし、調整し、最終化します。そのプロセスを中断するものがある場合（著者からの質問、流通業者からの遅延支払い、数値を確認する必要がある同僚）、同じファイルの複数のバージョンで終わります。
Royalties_Q3_FINAL.xlsx、Royalties_Q3_FINAL_v2.xlsx、Royalties_Q3_FINAL_v2_DAN.xlsx。聞き覚えがありますか？2人が同じロイヤリティファイルで作業する場合、変更をマージしたり競合にフラグを立てたりするための組み込みメカニズムはありません。結果は、どのバージョンが権威的であるかについての混乱と、間違った数値が送出される実質的なリスクです。
流通業者全体でのコピーペーストエラー
ほとんどの出版社は複数の流通業者から売上データを受け取ります。Amazon KDP、Lightning Source、Ingram CoreSource、ACX、Draft2Digital、およびその他のすべてが、異なる形式で異なる列レイアウトでレポートを提供します。そのデータをマスタースプレッドシートに取得することは、毎期すべてのコピー、貼り付け、および再フォーマットを意味します。
各コピーペーストは間違える機会です。間違った行に貼り付けるとある著者の売上が別の著者に属するようになります。列を逃すと正味収入が消えます。誤って前四半期のデータを上書きしてしまうと、バックアップを掘り返さない限り、それを復元する方法がありません（存在する場合）。
カタログが成長し、さらに多くの販売チャネルを追加するにつれて、毎期ジャグリングしているファイルの数が増えます。5タイトルで午後かかったことが、50タイトルで数日かかる可能性があります。
監査証跡がない
スプレッドシート内の数値が変更される場合、それを変更した人、変更した時期、または理由の記録はありません。著者が2年前のロイヤリティ数値に異議を唱える場合、古いファイルを検索して何が起こったかを再構築できることを望むしかありません。
これは単なる不便ではありません。監査可能性は税務報告、契約コンプライアンス、および権利保有者との信頼維持のために重要です。スプレッドシートは、適切なシステムが自動的に維持する種類の変更履歴を提供することはできません。
段階的ロイヤリティは悪夢になります
多くの出版契約には段階的ロイヤリティレートが含まれており、著者に支払われる割合は特定の売上閾値に達した後に増加します。たとえば、最初の5,000ユニットで10%、次の5,000で12.5%、その後15%です。
これをExcelで実装するには、複数の期間にわたって累積売上を追跡し、契約ごとに異なるティアを処理し、単一の期間の売上をレート境界全体で分割するネストされたIF数式を記述する必要があります。これらの数式は脆く、検証しにくく、元の著者以外の誰かが維持することはほぼ不可能です。
異なるティア構造を持つ数十の契約がある場合、複雑さは管理不可能になります。1つの閾値が間違うと、著者が誰も気づく前に数ヶ月間未払い（または過払い）になります。
前払い追跡がない
前払いは、スプレッドシートが苦労するもう1つの領域です。著者に将来のロイヤリティに対する前払いを支払う場合、未獲得残高を追跡し、前払いが回収されるまで獲得ロイヤリティを差し引く必要があります。これは自動的に、期間全体で発生する必要があり、該当する場合は同じタイトルに複数の前払いを考慮する必要があります。
スプレッドシートでは、これは期間から期間への実行残高の維持、前払いが完全に獲得されているかどうかの手動確認、および正しい時点での控除モードから支払いモードへの切り替えを意味します。それは退屈で、エラーが発生しやすく、ソフトウェアで処理されるべき論理そのものです。
ステートメント生成がない
すべての計算の後、各権利保有者のロイヤリティステートメントを作成する必要があります。Excelでは、これは各著者のシートを手動でフォーマットするか、複雑なメールマージプロセスを構築することを意味します。どちらの方法でも、数時間かかり、別の潜在的なエラーのラウンドを導入します。
著者とエージェントは、タイトル、形式、および地域別に売上を分類した明確でプロフェッショナルなステートメントを期待しています。スプレッドシートからこれをすることは、一貫して正確に行うことは、全体プロセスの最も時間がかかる部分の1つです。
複合コスト
これらの問題の各々は分離して管理可能です。まとめると、出版社が「Excel地獄」と呼ぶことが多いプロセスを作成します。このプロセスは、毎期スタッフ時間の日数を消費し、エラーの絶え間ないリスクを伴い、カタログが成長するにつれてスケーリングが不十分です。全体的な財務状況について知りたい場合は、手動ロイヤリティ処理のコストに関する記事で数値を詳しく説明しています。
開始から終了まで最新のロイヤリティワークフローがどのように見えるかについて、より詳しく知るには、無料ガイドをダウンロードしてください。
Royalties HQがこれをどのように処理するか
Royalties HQは、スプレッドシートベースのロイヤリティプロセスを置き換えるために特別に構築されました。10の対応流通業者（Amazon KDP、Lightning Source、Ingram CoreSource、ACXを含む）からの売上データは、コピーペーストや再フォーマットなしで直接インポートされます。各ファイルはアップロード時に検証され、すべての売上ラインはインポートから最終ロイヤリティステートメントまで追跡されます。
段階的ロイヤリティレート、前払い追跡、通貨換算、およびステートメント生成はすべて自動的に処理されます。すべての変更がログされ、すべての計算が監査可能であり、ステートメントは1回のクリックで各権利保有者のために生成されます。スプレッドシートから離れた移行について考えている場合、プロセスはあなたが予想するより簡単です。出版社に最適なロイヤリティソフトウェアの選択に関するガイドでオプションを探索できます。
