FAQ

いいえ。会計ソフトを置き換えるものではなく、会計処理の前段となる「契約〜請求〜支払〜支払調書」までの取引管理に特化しています。

代替ではありません。電子契約で締結した内容を“その後の運用”につなげ、支払・帳票・証跡まで一元管理するのが主目的です。※契約書作成機能は順次対応予定です。

Excelのように「人の記憶や転記」に依存せず、契約条件・実績・支払明細・根拠が紐づいて“正しい状態”を保てる点です。

個人事業主を「支払・税務・帳票（支払調書）まで含めた運用」前提で扱い、企業側の管理業務を一気通貫で整える点が違いです。

いまExcelやメールでやっている確認・集計・差し戻しを、取引の流れに沿って画面化した設計です。慣れるほど“探す／突き合わせる”が減ります。

管理する人数・規模に応じた月額制です。初期費用を抑え、取引が増えても運用が破綻しない設計を想定しています。詳細は料金表／資料をご確認ください。

はい、一定の人数区分に応じて変わります。取引先が増えるほど手作業コストも増えるため、費用対効果が見えやすい料金体系です。

月契約・年契約いずれも想定しています。なお、履歴を残す運用設計のため、短期スポット利用より“継続運用”に向くサービスです。

現在のExcel（取引先・案件・支払情報）や契約条件が分かる情報があれば開始できます。

特別な開発は不要で、最短で数日〜1週間程度で運用開始できる想定です（規模・整備状況により変動）。

問題ありません。途中月からの運用開始や、段階的な移行にも対応できます。

CSV等での移行を想定しています。どこまで過去を載せるかは、運用方針に合わせて設計します。

基本は企業側（管理者）が行います。現場運用に合わせた分担設計も可能です。

企業からの依頼内容を確認し、必要に応じて報告・実績入力、明細の確認・同意を行います。

運用に応じて、明細・帳票の自動生成（または出力）を前提に設計しています。

リマインドや、管理者側での対応（状況把握・催促・確定処理）を想定しています。

差し戻し・再編集を前提とした設計です。やりとりを履歴として残しながら修正できます。

はい。削除ではなく“履歴を残した補正”として変更できます（証跡を保つ運用）。

エラーとして検知し、支払データ作成前に気づける設計を想定しています。

エラーとして検知し、支払データ作成前に気づける設計を想定しています。

問題ありません。取引先×案件×期間の管理を前提としています。

振込先情報を含む、実務（振込・会計連携）で使いやすい形式を想定しています。

併用前提です。個人事業主くんは会計ソフトの前段を整え、CSV出力等で既存業務につなげます。

はい。登録状況（登録済／申請中／未登録等）を管理し、区分に応じた処理を想定しています。区分が変わっても、過去明細は原則として維持します。

対応を前提に、請求書・証憑を整理して保存できる運用（ダウンロード・保管）を想定しています。最終的な保管方法は社内ルールに合わせて運用します。

年次業務として支払調書の作成・出力を前提に設計しています。

契約・実績・支払・計算根拠が紐づいて残るため、メールやExcelをかき集める運用より説明しやすくなります。

法改正を前提にアップデートしていく方針です。過去データへの影響を抑えながら運用できる設計を目指します。

税務・法務・監査の観点では、削除よりも「履歴が残る状態」の方が説明しやすく安全だからです。

“消せない＝危険”ではなく、“消せない＝証跡が残る”という考え方です。誤りは削除ではなく差し戻し・補正で対応します。

アーカイブ／非表示など、運用に合わせて整理できる設計を想定しています。

はい。期限超過や例外時に、管理者が確定・補正できる運用を想定しています（履歴は保持）。

企業側（管理者）と個人事業主側で役割を分け、必要な操作範囲を明確にする設計です。

むしろ少人数運用ほど、属人化やミスの影響が大きいため効果が出やすいケースがあります。

はい。運用しながら整備していく前提でも導入できます。現状に合わせた“無理のない運用設計”をご提案します。

既存のExcel運用ができていれば問題ない想定です。導入時は稟議・運用定着も含めて支援します。

以後の取引は法人として扱い、過去の取引履歴は保持する運用を想定しています。

条件・金額・履歴が明確になることで、認識違いが減り、結果的にトラブルが減るケースが多いです。

年に数件程度で、取引管理の工数やリスクがほとんど発生していない企業は、費用対効果が出にくい可能性があります。

エラーとして検知し、支払データ作成前に気づける設計を想定しています。