基幹システムと他システムを連携する項目の決め方｜小規模で最初につなぐ流れと揃えておくマスタ

◆監修・編集責任者　小園 将隆　2026年10月13日

B2B EC-COLUMN

二重入力の正体は「どの項目が、どこで生まれるか」が決まっていないこと

販売管理の画面で入れた受注や請求を、月末に会計ソフトへもう一度打ち直していませんか。
基幹システムと他のシステムをつなぐとき、最初に決めるのはCSVかAPIかという方法ではありません。
項目ごとに「どのシステムで生まれ、どこへ渡すか」を決めることです。
手入力の回数が多く、間違えると請求や仕訳に響く流れから一つずつつなぎ、方法は更新の頻度と、エラーを見られる人がいるかで選びます。
つなぐ前には、勘定科目・税区分・取引先の名称とコードを揃えておきます。
ここがずれていると、取込のたびにエラーで止まります。

項目・発生元・渡し先・頻度の表をつくる

仮の例で考えます。
販売管理システムで受注を入力し、出荷後に同じ画面から請求書を発行している会社があるとします。
月末になると、経理を兼ねる担当者が請求一覧を見ながら、会計ソフトへ売上の仕訳を一件ずつ打ち直しています。
入金があれば、通帳と請求書を見比べてどの請求の入金かを確かめ、会計ソフトに入金の仕訳を入れます。
この会社では「誰に、いくら売ったか」という一つの事実が、受注、請求書、売上仕訳、入金仕訳と形を変えて、何度も手で入力されています。

手間だけが問題なら、入力を急げば済むかもしれません。
困るのは、同じ値が二か所にあるのに、どちらが正しいかが決まっていないことです。
請求後に値引きが決まって販売管理の金額を直したのに、会計ソフトの仕訳は元の金額のまま残る。
会計ソフトで取引先の社名変更を反映したのに、販売管理の請求書は旧社名のまま出ていく。
どちらも、その項目の持ち主がどこかを決めていないために起きるずれです。
連携とは、項目ごとに持ち主のシステムを一つ決め、ほかのシステムはその値を受け取る側に回すことだと考えると、決める順番が見えてきます。

そこで、方法を選ぶ前に一枚の表を作ります。
列は「項目」「発生元（その値を最初に作り、正とするシステム）」「渡し先」「頻度」の四つです。
「会計連携」「EC連携」のように機能の名前で書くと、何を渡すのかがぼやけます。
「請求確定時の売上」「取引先の名称とコード」のように、項目の単位まで下ろして書くのがこつです。

書き方で迷いやすいのは発生元の欄です。
受注や請求のように一方の画面でしか作らない項目は、すぐ埋まります。
迷うのは取引先のように、販売管理でも会計ソフトでも登録できてしまう項目です。
両方で作れる状態のまま連携すると、同じ会社が別の名前やコードで二件できたり、片方の変更がもう片方に届かなかったりします。
どちらを持ち主にしても構いませんが、一つに決めて、もう一方では作らない運用にしておくと、後の対応付けが楽になります。
頻度の欄には「都度」「日次」「月末にまとめて」のような更新の間隔と、おおよその件数を添えておくと、連携方法を選ぶときにそのまま使えます。

この表は記事が提案する整理のしかたで、決まった様式があるわけではありません。
「誰が入力しているか」「間違えたときにどこへ響くか」の列を足してもよく、優先順位を付ける段階ではむしろその二つが判断材料になります。
大事なのは、表を埋める過程で、二重入力している項目と、持ち主が決まっていない項目が目に見えるようになることです。

表の項目を業務の流れに並べ直すと、受注から請求、入金、仕訳へと値が受け渡されていく一本の線になります。
取引先や商品、勘定科目といったマスタ（取引のたびに参照する基本情報）は、この線のどの段でも参照されます。
線の上で手で打ち直している箇所が、連携の候補です。

「小規模」とは：人数の基準は制度で違う

ここまで「小規模」という言葉を使ってきましたが、人数の基準は法律や制度によって違います。
中小企業基本法は、小規模企業者を、おおむね常時使用する従業員の数が20人以下、商業又はサービス業を主たる事業とする場合は5人以下の事業者と定めています¹。
中小企業基盤整備機構が示す中小機構法上の定義では、商業（卸売・小売）とサービス業（宿泊・娯楽を除く）が5人以下、工業・鉱業・運送業・宿泊業・娯楽業などが20人以下とされています²。
補助金や支援制度の対象かどうかを確かめるときは、その制度がどの定義を使っているかを所管の案内で見ることになります。

一方、連携の設計で効いてくるのは、人数の線引きそのものより、少ない人数で役割を兼ねていることです。
項目表を作る人と、毎月の取込でエラーを見る人と、会計ソフトのマスタを変える人が同じだったり、隣の席にいたりします。
専任のシステム担当がいない分、連携する流れを増やすほど、一人が抱える確認先も増えます。
一つの流れから始めることや、エラーを見る人を決めておくことが少人数の会社で特に効いてくるのは、この事情があるからです。

▼ 図の内容を文字で読む

• 一方の画面でしか作らない項目
  • 受注
  • 請求
• 両方で登録できてしまう項目
  • 取引先
  • 別の名前やコードで二件できる
• 持ち主の決め方
  • どちらかを持ち主に一つ決める
  • もう一方では作らない運用にする

会計との連携で実際に渡る項目：仕訳・マスタ・取引先

書き込む項目：仕訳・明細・証憑

項目表の渡し先に会計ソフトが並んだら、次は相手が実際に何を受け取れるかを見ます。
表の上でつなぎたい項目でも、受け取る側に受け口がなければデータは流れません。
受け口は会計ソフトごとに違うため、ここでは公開仕様が確認できるマネーフォワード クラウド会計のAPIを例にします。
API（Application Programming Interface）は、システム同士が決められた手順でデータを直接やり取りするための窓口です。

同社が公開しているAPIの説明では、会計ソフトへ書き込める対象として、仕訳の作成・更新・削除と一覧の取得、証憑（請求書や領収書などの根拠書類）の保存と仕訳への添付が挙げられています³。
また、クラウド会計などを利用していれば、API利用に追加料金はかからないとされています³。
これは同製品について、ページに記載された時点の仕様で、他の会計ソフトにそのまま当てはまるものではありません。

前の節の仮の例に当てはめると、「請求確定時の売上」は、会計ソフトへの仕訳の作成として渡せる項目になります。
更新や削除の受け口もあるので、販売管理で請求を訂正したときに、会計ソフトの仕訳も追随させる設計が考えられます。
ただし、会計ソフト側に受け口があることと、自社の販売管理が訂正をデータとして送り出せることは別の話です。
販売管理側が新規の請求しか書き出せないなら、訂正分は手で直すか、送り直し方を決めることになります。
受け口は相手側の仕様、送り出しは自社側の仕様として、両方を表に書き込んでおくと、つないだ後に「訂正だけ流れない」と気づく事態を避けやすくなります。

参照する項目：科目・税区分・部門・取引先

書き込みとは逆向きに、会計ソフトから読み出して使う項目もあります。
同じAPIでは、勘定科目、補助科目、税区分、部門、取引先を取得でき、取引先は新規に作成することもできます³。
勘定科目や税区分は会計ソフトが持ち主で、販売管理側はその一覧を読み出し、「この売上はどの科目・どの税区分か」を対応付けるために使う、という向きになります。

注意したいのは取引先です。
読み出すことも作ることもできるので、両方向に動く項目になります。
項目表で取引先の発生元を決めていないと、販売管理で登録した取引先が連携のたびに会計ソフトで新規作成され、会計ソフトに先に登録していた同じ会社と並んでしまう、ということが起こりえます。
APIの仕様が両方向を許していても、自社の運用ではどちらか一方を持ち主にしておく理由はここにあります。

他の会計ソフトや、ECや請求の仕組みと連携するときも、見る点は同じです。
自社の相手先について、次の点を仕様書や提供元の案内で確かめておくと、表の渡し先の欄が埋まります。

• 仕訳（または取引）を外部から作成できるか
• 作成した仕訳を外部から更新・削除できるか
• 勘定科目・税区分・部門などのマスタを外部から読み出せるか
• 取引先を外部から作成できるか、作成された取引先を既存のものとどう見分けるか
• 証憑を仕訳に添付できるか

▼ 図の内容を文字で読む

• 仕訳と証憑を書き込めるか
  • 仕訳を外部から作成できるか
  • 作成した仕訳を更新・削除できるか
  • 証憑を仕訳に添付できるか
• マスタを読み出せるか
  • 勘定科目・税区分・部門を外部から読み出せるか
• 取引先をどう扱えるか
  • 取引先を外部から作成できるか
  • 既存のものとどう見分けるか

小規模ではどの流れから連携するか

優先順位を付ける3つの軸

表ができると、手で打ち直している項目がいくつも並びます。
全部つなげば二重入力はなくなりそうに見えますが、少人数の会社では、最初から全部をつなぐと別の負担が出ます。
取込でエラーが出たとき、どの流れのどの項目が原因かを切り分ける作業が、表を作った同じ一人に集中するからです。
一つの流れをつないで、エラーの出方と直し方がつかめてから次へ広げるほうが、原因を追いやすくなります。

どの流れから始めるかは、次の三つの軸で並べると決めやすくなります。
これは記事が提案する考え方で、効果を測って得た順位ではありません。

• 手入力の頻度と件数：毎日、あるいは月末にまとまった件数を打ち直している流れほど、連携で減る転記が多い
• 間違えたときの影響：請求金額、入金の消込、売上や消費税の仕訳のように、誤りが取引先への請求や決算・申告へ響く項目ほど優先が上がる
• 受け口の有無：渡し先にすでに受け口があり、自社側からも送り出せる流れほど、始めるまでの準備が少ない

仮の例に当てはめると、「請求確定時の売上を会計ソフトの売上仕訳へ渡す」流れは、月末に件数が集まり、誤ると売上と消費税の計算に響き、会計ソフト側には仕訳を作る受け口があります。
三つの軸のどれでも上位に来るので、最初の候補になります。
反対に、商品の情報をECサイトへ渡す流れは、件数や更新の多さによっては候補になりますが、EC側がどの項目を受け取れるかは製品ごとに違うため、受け口の確認から始めることになります。
表の各行に三つの軸で印を付けて並べてみるだけでも、どこから手を付けるかを社内で話し合いやすくなります。

相手方の対応が要る流れ：入金情報の例

三つ目の軸の受け口は、自社と会計ソフトの間だけで決まるとは限りません。
入金の流れがその例です。
仮の例の会社では、通帳に並んだ振込名義と金額を見て、どの請求への入金かを人が判断しています。
複数の請求をまとめて振り込まれたり、振込手数料が差し引かれていたりすると、照らし合わせに時間がかかり、間違いも起きやすくなります。

中小企業庁のミラサポplusが紹介している全銀EDI（ZEDI）は、この照らし合わせを取引データで支える仕組みです。
支払側が振込と同時に請求番号などの請求内容の情報を送り、受取側はどの請求への入金かをデータで把握できます⁵。
ただし、支払側と受取側の双方が導入していることと、受取側のソフトが自動消込に対応していることが前提とされています⁵。
この記事は2019年1月の取材に基づくもので、手数料や対応するソフトは、現在の金融機関やベンダーの案内で確かめる必要があります。

優先順位の判断に戻すと、入金の流れは誤りの影響が大きくても、取引先が請求情報を付けて振り込んでくれなければ、受け取るデータそのものがありません。
自社だけで準備できる流れと、相手方の対応を待つ流れを分けて考えると、最初の一つは前者から選ぶことになりやすいでしょう。
入金の流れは、主な取引先の振込のしかたと、自社の会計ソフトの対応を見ながら、後の候補として表に残しておけます。

▼ 図の内容を文字で読む

• 手入力の頻度と件数
  • 毎日、または月末にまとまった件数を打ち直している流れ
• 間違えたときの影響
  • 請求金額、入金の消込、売上や消費税の仕訳
  • 取引先への請求や決算・申告へ響く項目
• 受け口の有無
  • 渡し先にすでに受け口がある
  • 自社側からも送り出せる

連携方法の選び分け：CSV取込・API・連携サービス・手入力の継続

比較の軸と確認項目

最初の流れが決まったら、つなぎ方を選びます。
選択肢は大きく四つあります。
CSV取込は、送る側からCSVファイル（項目をカンマで区切った表形式のファイル）を書き出し、受け取る側の画面から取り込む方法です。
APIは、前の節で見た窓口を使って、システム同士が直接データを受け渡す方法です。
連携サービスは、二つのシステムの間に入り、データの変換や受け渡しを担う別のツールを使う方法です。
そして、連携せずに手入力を続けることも、項目によっては選択肢に入ります。

同じ会計ソフトが、CSVとAPIの両方を用意していることもあります。
マネーフォワード クラウド会計では、APIで仕訳の更新・削除や取引先の新規作成まで扱えます³。
CSVの仕訳インポートでは、既存の仕訳を更新するときに更新用IDという値を使い、そのIDが現在の事業者に存在しない場合はエラー3となって更新されません⁴。
CSVでも訂正を取り込む道はあるものの、どの仕訳を直すのかを、ファイルの中のIDで正しく指し示す必要があるということです。
どちらが優れているかではなく、自社の流れの性質とどちらが噛み合うかで選びます。

比べるときの軸は、項目表の頻度の欄と、自社の体制から取れます。
更新の頻度、1件ごとに人が確認する必要があるか、エラーが出たときに人が見て直せるか、仕組みを保守する人がいるか、の四つです。

表のうち判断が分かれやすいのは、頻度と確認の兼ね合いです。
月末に一度、請求一覧をまとめて渡す流れなら、CSV取込は取り込む前にファイルを開いて金額や取引先を目で確かめられるので、少人数でもエラーを人が追えます。
一方、日々の注文や訂正を都度渡したい流れでは、毎回ファイルを書き出して取り込む操作そのものが新しい手作業になり、APIで送り出すほうが噛み合います。
その代わり、APIは送り出す仕組みを誰かが作り、エラーが起きたことに気づける形にしておかなければなりません。
仮の例の会社のように、最初の流れが月末の売上仕訳であれば、まずCSV取込で始め、件数や訂正が増えてきた段階でAPIを検討する、という段階の踏み方も取れます。

連携サービスは、自社で送り出しの仕組みを作らずに済む点が魅力です。
ただ、どの項目に対応しているか、費用がどう決まるか、仕様が変わったときに設定を直すのは誰かは、サービスと契約によって違います。
ここで一般的な相場や優劣を示すことはできないので、候補が挙がったら、項目表の行がそのサービスで渡せるかどうかを一行ずつ当てていくのが確かな比べ方です。

手入力を残す判断

連携は手入力を減らすための手段で、すべての項目に使う必要はありません。
件数が月に数件しかない流れや、値引きの調整、相殺のように毎回判断が要る取引は、連携の設計に例外処理を盛り込む手間のほうが大きくなることがあります。
マスタがまだ揃っていない段階でつなぐと、次の節で見るように取込のたびにエラーで止まり、手入力より時間がかかることもあります。

手入力を残すと決めた項目も、項目表から消さずに「手入力」と書いておきます。
誰が、いつ、何を見て入力し、どこで照らし合わせるかを書き添えておけば、連携した流れと手入力の流れの境目がはっきりし、二重入力が残っている場所を自覚したまま運用できます。
件数が増えたり、マスタが整ったりした時点で、もう一度三つの軸で見直せば足ります。

▼ 図の内容を文字で読む

• 更新の頻度
  • 月末にまとめて渡すならCSV取込から
  • 日々の注文や訂正を都度渡すならAPI
• 1件ごとの確認
  • 取り込む前にファイルを開いて金額や取引先を目で確かめられる
• エラーを見る人
  • エラーが出たとき人が見て直せるか
  • APIはエラーに気づける形にしておく
• 保守する人
  • APIは送り出す仕組みを誰かが作る
  • 件数や訂正が増えたらAPIを検討

つなぐ前に揃える：科目・税区分・取引先の名称とコード

エラーで見る不一致の現れ方

どの方法を選んでも、受け取る側に存在しない科目や区分を渡せば、取込は止まります。
マネーフォワード クラウド会計の仕訳インポートのエラー一覧には、勘定科目が存在しない（エラー19）、勘定科目が無効になっている（エラー20）、税区分が使えない（エラー26）、税区分とインボイスの列の組み合わせが正しくない（エラー30）といったエラーが並んでいます⁴。
名前や区分が一致しないことは、取込の場面ではこうした形で表に出ます。

仮の例の会社で考えてみます。
販売管理では売上の科目を「売上高」と呼び、会計ソフトでは「売上」になっていれば、会計ソフトから見ると存在しない科目が送られてきたことになります。
会計ソフト側で以前の科目を使わない設定にしていれば、名前が合っていても無効な科目として扱われます。
税区分も、販売管理が持つ区分の名前と、会計ソフトで使える税区分が違えば止まります。
インボイス制度に関わる列は税区分との組み合わせまで見られるので、一列だけ揃えても通らないことがあります。

APIの場合も、前に見たとおり、勘定科目や税区分は会計ソフト側から読み出して対応付けに使う項目です³。
同じ提供元の資料から読み取れる範囲ではありますが、CSVでもAPIでも、送る側の科目や税区分が受け取る側の一覧と対応していなければ失敗する、という点は変わらないと考えられます。
他の会計ソフトでのエラーの出方は製品ごとに異なりますが、方法を変えればマスタのずれが消える、というものではありません。

揃える順序

揃える作業とは、送る側の名称・コードと、受け取る側の名称・コードを一行ずつ並べた対応表を作ることです。
名前そのものを揃える方法と、名前は違ってもコードで結び付ける方法がありますが、どちらにしても対応関係が一か所に書かれていることが大切です。
順序は、次のように仕訳の骨格から外側へ進めることを提案します。

勘定科目を先にするのは、売上や入金がどの科目に入るかが決まらないと、仕訳の形そのものが決まらないからです。
税区分は科目と組み合わせて使われ、インボイスに関わる列とも組み合わせを見られるので、科目の後に決めます。
取引先は、項目表で決めた持ち主の側を正として、もう一方の名称とコードを合わせます。
商品は販売管理が持ち主になる項目で、会計ソフトへは商品ごとではなく科目や部門に集約して渡す設計なら、商品と科目の対応を最後に決めれば足ります。

最初の取込でエラーの一覧を見ながら一つずつ直していくやり方に比べ、対応表を先に作っておけば、どこを直せばよいかが分かった状態で始められます。
対応表は、次に見る運用の段階でも、エラーの原因をたどるときの手がかりになります。

▼ 図の内容を文字で読む

• 勘定科目のずれ
  • 勘定科目が存在しない（エラー19）
  • 勘定科目が無効になっている（エラー20）
• 税区分のずれ
  • 税区分が使えない（エラー26）
• インボイスの列との組み合わせ
  • 税区分とインボイスの列の組み合わせが正しくない（エラー30）

連携を始めたあと：エラーと変更に備える

マスタ変更を連携先へ反映する

対応表を作り、最初の流れがつながっても、マスタは動き続けます。
勘定科目を無効にしたり、税区分の設定を変えたりすると、それまで通っていた取込がエラーになります⁴。
仮の例の会社で、決算の後に会計ソフトの科目を整理し、使わなくなった科目を無効にしたとします。
販売管理側の対応表が古いままなら、翌月の取込で、整理した科目へ向けた売上がエラー20で止まります。
導入前に揃えた不一致は、運用の途中でも同じ形で戻ってきます。

これを避ける手立ては、マスタを変える操作と、連携の対応表を直す操作を一組の手順にしておくことです。
会計ソフトで科目や税区分を変える人が、その日のうちに対応表と送る側の設定も直す。
取引先の名称が変わったときは持ち主の側で直し、もう一方へ渡るかどうかを次の取込で確かめる。
少人数の会社では、変える人と直す人が同じになりやすいので、マスタ変更の手順に一行足すだけでも、翌月の取込で気づくはずだったずれを、変更した当日に直せます。

CSVで訂正を取り込むときの扱いも、日常の確認に入れておきます。
更新用IDが現在の事業者に存在しない場合はエラー3となり、既存の仕訳を更新できません。
その場合は、CSVを再エクスポートし、更新用IDを変えずに取り込むよう案内されています⁴。
ファイルを加工する途中でID列を消したり、別のファイルの行を貼り付けたりしないことを、取込を担う人の決まりにしておくと迷いが減ります。

エラーを見る担当と頻度

最後に、エラーを誰が、いつ見るかを決めます。
見る頻度は取込の頻度に合わせるのが自然で、月末にまとめて取り込むなら取込の直後、日次で送るなら毎日決まった時間、という具合です。
見る人は、項目表と対応表を作った人か、その内容を引き継いだ人にしておくと、エラーの内容から、どの対応がずれているかをたどれます。

エラーを見たときに確かめる順番も決めておけます。
まずエラーの内容から、科目・税区分・取引先・更新用IDのどれが原因かを見分けます。
次に、それが送る側の入力の誤りなのか、対応表が古いのか、受け取る側のマスタが変わったのかを切り分けます。
対応表のずれが原因なら、エラーになった行だけでなく対応表そのものを直しておかないと、次の取込で同じエラーが出ます。

こうした決まりを作っても、連携の誤りがなくなると約束できるわけではありません。
変わるのは、ずれが起きたときに、どの表のどの行を見ればよいかが先に分かっていることです。
手で打ち直していた転記が減った分、確認の場所を項目表と対応表に集めておくことが、少人数で連携を続けるための土台になります。

▼ 図の内容を文字で読む

1. エラーの内容から原因の項目を見分ける：科目・税区分・取引先・更新用IDのどれか
2. 原因の所在を切り分ける：送る側の入力の誤りか、対応表が古いか、受け取る側のマスタが変わったか
3. 対応表そのものを直す：行だけ直すと次の取込で同じエラーが出る

項目表を作っても、自社の販売管理が送り出せる項目や、相手側の受け口、マスタのずれは、画面や仕様書を見比べるだけでは判断しにくいところが残ります。

項目表をもとに、最初につなぐ流れと連携方法、先に揃えるべき科目・税区分・取引先を一緒に整理し、自社で決めることと相手先に確かめることを切り分けられます。無料相談で要件を整理する

要点の整理

軸	基準
最初に決めること	項目ごとの発生元（持ち主）・渡し先・頻度
始める流れ	手入力の頻度、誤りの影響、受け口の有無で上位に来る一つ
方法の選び方	更新の頻度、1件ごとの確認、エラーを見る人、保守する人
手入力を残す項目	件数が少ない・例外が多い流れ。表に「手入力」と担当を書く
つなぐ前の準備	勘定科目→税区分→取引先→商品の順に対応表を作る
運用	マスタ変更と対応表の修正を一組にし、エラーを見る人と頻度を決める

連携を始めた後は、マスタの変更やエラーへの対応を少人数で回し続けることになり、どこまでを仕組みに任せ、どこを人が見るかの線引きに迷いやすくなります。 取込の頻度と体制に合った確認の手順や、エラーが出たときに見る順番を、自社の項目表と対応表に沿って確かめられます。

よくある質問

連携する項目は、全部そろえてから始めるべきですか。一つの流れから試すべきですか。

一つの流れから試すことをおすすめします。
少人数では、最初から全部をつなぐと、エラーの原因を切り分ける作業が一人に集中しやすいためです。
ただし、つなぐ流れで使う勘定科目・税区分・取引先の対応表は、始める前に作っておきます。
すべてのマスタを揃え終える必要はありませんが、その流れに関わる分が揃っていないと、取込のたびにエラーで止まります。

CSV取込とAPI連携は、どんな頻度・件数で使い分けるのですか。

何件以上ならAPI、という決まった基準はありません。
月末などにまとめて渡し、取り込む前にファイルを目で確かめたい流れはCSV取込が噛み合います。
都度や日次で渡し、訂正も多い流れは、毎回の書き出しと取込が新しい手作業になるため、APIが向いています。
ただしAPIは、送り出す仕組みを作り、エラーに気づける形で保守する人が必要です。
会計ソフトによっては両方を用意しているので、CSVで始めて後からAPIへ移る進め方も取れます。

会計ソフトを入れ替えるとき、連携のマスタはどこまで作り直しになりますか。

項目ごとに発生元と渡し先を決めた項目表の考え方は、そのまま使えます。
作り直しになるのは、新しい会計ソフトの勘定科目・税区分・取引先の一覧に合わせた対応表と、受け口の確認です。
仕訳を外部から作成・更新・削除できる範囲や、マスタを読み出せるかどうかは製品ごとに違うため、表の渡し先の欄から見直します。
どこまで手を入れるかは、新旧の製品の仕様の差によって決まります。

取込でエラーが出たとき、誰がどの順で確認すればよいですか。

項目表と対応表を作った人か、その内容を引き継いだ人が見るのが近道です。
まずエラーの内容から、科目・税区分・取引先・更新用IDのどれが原因かを見分けます。
次に、送る側の入力の誤りか、対応表が古いのか、受け取る側のマスタが変わったのかを切り分けます。
対応表のずれが原因なら、対応表そのものも直しておくと、次の取込で同じエラーが出るのを避けられます。

従業員が数人の会社でも、連携の保守担当は置く必要がありますか。

専任の担当者を置く必要はありませんが、役割には名前を付けておくことをおすすめします。
具体的には、取込の後にエラーを見る人と、会計ソフトのマスタを変えたときに対応表も直す人です。
兼任で構いませんが、誰の仕事か決まっていないと、マスタの変更が連携先へ伝わらず、翌月の取込で初めてずれに気づくことになります。

1. 1　出典：e-Gov法令検索「中小企業基本法 第2条」（現行法令）
2. 2　出典：独立行政法人中小企業基盤整備機構「中小企業・小規模企業者の定義」（2026年）
3. 3　出典：株式会社マネーフォワード「マネーフォワード クラウド会計のAPI」（2026年）
4. 4　出典：株式会社マネーフォワード「マネーフォワード クラウド会計使い方ガイド 仕訳インポート（エラー一覧）」（2026年）
5. 5　出典：中小企業庁（ミラサポplus）「金融EDIの導入で、経理業務を効率化する！」（2020年）