会計ソフトと業務システムの連携前に何を決める？仕訳データ・締め・訂正の確認点

最初に、どの取引を何のために渡すか決める

最初に選ぶのは連携方式ではなく、減らしたい仕事と、対象にする取引です。例えば「販売側で確認した請求情報を使い、経理の転記を減らしたい。その後の訂正と月末の照合を追えるようにしたい」と、担当者の仕事から説明します。請求の連携に、入金の消込や銀行への支払まで含むかは別に決めます。

会計連携、仕訳、転記、締めの意味を合わせる

ここでいう会計連携は、販売・購買などの業務側の情報を会計ソフトへ渡し、必要な確認を経て会計の記録へ結び付ける仕組みです。仕訳は取引を勘定科目や金額などで会計上の記録に表すこと、転記はその情報を別の記録へ写すことを指します。入力の手間が減っても、取引の意味や記録内容の確認が不要になるとは限りません。

締めは、ある期間の取引と会計記録を確認し、その期間の扱いを区切る仕事です。製品の期間ロック、会社の月次確認、決算などは同じ意味とは限りません。この記事の「計上」は、確認すべき帳簿へどう反映されたかを扱う言葉として使います。製品ごとに登録・承認・転記などの名称や区切りが異なるため、自社で使う状態名と対応させます。

請求草案から、会計側へ渡せる条件を尋ねる

最初の架空例は、販売側の請求草案です。部品の請求草案という種類で、元の草案は存在します。照合のための取引番号はS-17（架空）、版は草案1です。この番号は説明の見出し用記号ではなく、元と送り先の同じ取引を追うための目印です。以下では「販売の請求草案」と呼びます。

草案は2明細で、草案額は12,000円です。ただし、税・送料の扱いは未確認の草案額であり、課税額や税込総額を決める数値ではありません。元に記録があることは、確定した請求や売上計上を示すことでもありません。

この例の送り先は会計ソフトへ渡す候補で、送信は試みていません。経理の了承も未確認です。方式を決めた、元の金額がある、という理由だけで送ってよいとはしません。

一般的なファイルの受領・検査・途中停止の設計は、毎朝のファイル連携で決める入口と出口の話と分けます。本稿の中心は、会計側で使う項目、期間、状態、訂正、照合の条件です。

元の明細と、会計側の項目を対応させる

名前が似た項目をつなぐ前に、一件の意味と単位をそろえます。元の請求一件が会計側でも一行になるとは限りません。複数の元明細をまとめる場合も、一つの取引から複数の会計記録ができる場合もあります。どちらも、元へ戻って内訳を確かめられることが必要です。

明細で渡すか、まとめて渡すかを決める

明細単位で渡すときは、どの元番号と明細番号が、どの会計記録へ対応するかを定めます。日次などで集計するなら、集計する軸と期間、含む元明細、除外や訂正の扱いを決めます。集計額だけを渡し、あとから差の理由を調べる方法がないと、転記は減っても照合の負担が残ります。

販売の請求草案の連携する単位は未決定です。2明細という元の数から、仕訳の行数や送信件数を補ってはいけません。12,000円という合計だけでなく、どの明細のどの版を含むかを、対応する識別情報と一緒に示す方法を相談します。

項目ごとに、意味・管理元・変換・確認担当を決める

次の表は、連携仕様を話すときの観点です。実際の列名や必須項目は、対象製品と会社の会計方針で確認します。同じ「日付」「金額」という名前でも、元と先で意味が異なる場合はそのまま写しません。

一つの元取引で確認する、項目の意味と対応

金額は、通貨、正負の表し方、単位、税を含む範囲、値引きや端数の扱いまで対応させます。税込・税抜の変換や税区分は、架空の金額から決めず、経理が適用条件を判断します。必要な貸方・借方や残高への影響も、期待する会計処理と製品仕様に沿って確認してください。

この草案では、会計日付と会計期間は未決定です。勘定科目、部門コード、税の扱いも未決定です。送信日を自動で会計日付へ写す、空欄なら既定の科目でよい、と先に決めてはいけません。

コードが変わるとき、過去の記録を変えない条件も聞く

取引先、部門、勘定科目などのコードについて、管理元、対応表の版、適用開始日、未登録時に止める場所、変更の確認担当を定めます。対応表の更新で次回以降だけ変わるのか、既に登録された記録にも影響するのかを、提供会社に尋ねます。

例えばMoney Forwardの公式説明には、連携データからの仕訳候補と登録の区別や、既定の勘定科目を変えても既に登録した仕訳は変わらない扱いが示されています。これは同製品の説明です。自社の製品でも同じとは決めず、未登録分・既登録分・締め済み分のどこへ変更が効くかを確認します。

送信・候補・登録・計上・照合を分ける

「連携完了」の一語を、その会社が確認する状態へ分けます。送信側の処理が終わっても、会計側が受け付けたとは限りません。受け付けても検査待ち、入力候補のまま、人の確認待ち、という場合があります。以下は確認の観点であり、すべての製品に同じ画面や順番があるという意味ではありません。

送る前と、送信・受付の結果を分ける

送る前には、対象の状態、必須項目、対応表の版、送信対象の重複を確認します。送信後は、どの取引・版をいつ送ったか、受け側から何が返ったかを記録へ対応させます。通信が成功した表示だけでなく、受け側が受け付けた対象や、拒否・保留の理由を確認できる条件が必要です。

ファイル方式は情報を一定の形式のファイルで渡す方法、APIはシステム同士が決められた窓口で情報をやり取りする方法です。どちらでも、送る条件、受け側の検査、結果の追跡は別に決めます。応答に含む番号、件数、エラーの意味や、処理の完了を後から調べる方法を、現在の製品仕様に沿って確認します。

候補と登録、帳簿への反映を同じにしない

取り込んだ明細を仕訳候補として提示し、人の確認後に登録する仕組みもあります。登録後に承認や別の反映処理がある製品も、これらが同じ操作になる製品もあります。誰がどの内容を確認し、どの記録を見れば今回の反映を確かめられるかを定めます。

Microsoftの公式説明でも、補助元帳から総勘定元帳への転送には非同期や定時処理があり、依頼した時点と記録に現れる時点が同じとは限りません。一般仕訳の説明では、検証や模擬実行と実際の転記も区別されています。ここから「どの製品でもこの操作で終わる」とはせず、使う製品の処理状態と確認記録を読み合わせます。

販売の請求草案は、受け側の受付、仕訳候補の作成、仕訳の登録、帳簿への反映がすべて未確認です。元との照合、支払の完了も未確認です。未送信の草案から、どの状態も成功へ進めていません。

図で見る問い：元の請求に2明細・12,000円と書いてあれば、会計側も確認できたことになるでしょうか。元の紙に分かることと、会計側の記録を見なければ分からないことの境目を見てください。

この解説図を原寸で見る

図の読み方：元の草案が存在しても、送信・受付・登録・計上・照合を確認したことにはなりません。「未確認」の箇所は0件や失敗という意味でもありません。経理と製品担当に、同じ元取引のどの記録を見れば分かるかを尋ね、その記録と期待する内容を仕様へ追加します。

件数だけでなく、同じ対象と金額の内訳を照合する

照合は、元と先の対応を確かめる仕事です。元の取引番号・明細・版、対象期間、金額の意味をそろえ、取り込んだ分、保留した分、除外した分を区別します。一件が複数行へ分かれるなら、対応する行のまとまりへ戻って比べます。単に「元2行、先2行」だけでは、違う取引や古い版が入っていないかは分かりません。

総額が同じでも、違う部門や期間へ入った、別の取引と差が相殺された、という可能性があります。必要な分類と内訳まで照合する条件を決め、差があれば元の取引、対応表、受け側の記録のどこを調べるかを示します。貸借が合うことも検査の一つであり、対象・科目・期間が適切だという確認の代わりにはなりません。

結果不明・一部取込・重複は、元の取引へ戻る

例外では、エラー表示を消すことよりも、どの元取引が、どこまで記録されたかを調べることを先にします。分からないまま同じ情報を再送すると、二重登録や、訂正前後の混在につながるおそれがあります。実際の止め方・直し方は製品と会社の運用に合わせます。

送信結果が分からない：記録の有無を調べてから再送を判断

もう一つの架空例は、別の取引の訂正相談です。仕入先請求の訂正相談で、取引番号はP-09（架空）、版は訂正相談1です。元の相談記録は存在します。対象は1明細、草案額は8,000円ですが、訂正前後の差額と税の扱いは未確認の草案額です。

この相談の目的は会計ソフトの既存記録との対応確認です。送信を試みた記載はありますが、送信の結果は不明です。販売の請求草案とは別取引であり、12,000円から8,000円へ訂正した例ではありません。差額4,000円の処理も導いていません。

まず、送信対象の番号・版・明細、送信の記録と受け側の返答を対応させ、受け側の受付・保留・候補・既登録に同じ対象がないかを担当者が確認します。既に登録されていれば再送せず、その内容と対象版を照合します。未受付だと確認できた場合は、再送方法と同じ対象を識別する条件を提供会社へ確認します。所在が分からなければ、成功報告と再送を保留し、調査先と期限を残します。

訂正相談の受付、仕訳候補、仕訳登録、帳簿への反映は未確認です。元との照合と支払完了も未確認です。送信を試みたという記載から、先へ進んだ状態を推測しません。

一部だけ取り込まれた：処理済みと保留を同じ一覧で分ける

ファイルやまとめた送信の一部だけが受け付けられる設計なら、どの元取引・明細が受け付けられ、どれが拒否・保留されたかを追えるようにします。全体を戻す設計か、問題のある分だけ直す設計かを先に決め、正常分をもう一度取り込まない方法まで確認します。

受け付けた件数とエラー件数の合計だけでは、対象漏れは調べ切れません。送った対象一覧と、受け側の各結果が対応するかを照合します。訂正後の再実行で使う元の版と、完了した対象をどう引き継ぐかも要求に含めます。

同じ取引が二度届いた：番号だけでなく、版と処理結果を照合

同じ内容の再送、訂正した版、別取引を区別するために、元取引の識別子、明細、版と受け側の記録を対応させます。「同じ番号はすべて捨てる」だけでは正当な訂正を見失うことがあり、毎回追加するだけでは重複することがあります。重複を検知した結果、対象と理由を担当者へ示す方法を相談します。

コード・金額・期間が合わない：意味の判断と通信の修正を分ける

部門や科目が未登録なら、経理や管理元担当が正しい対応を判断し、連携担当が変換・検査条件を反映します。貸借の不一致、金額範囲や期間の違いは、元の値、変換結果、受け側の記録を分けて調べます。適当な既定値へ置き換え、取込を通すことを完了条件にしません。

訂正と締め後の扱いを、経理の判断へつなぐ

元データを直せば、会計側の記録も自動で直るとは限りません。未送信、受付後、候補のまま、既登録、締め済みなど、今の状態で必要な処理が変わります。訂正する前に元の取引、会計側の対応記録、変更理由、影響する期間と後続の仕事を合わせます。

訂正相談では、連携単位、会計日付、会計期間が未決定です。科目、部門コード、税の扱いも未決定です。対象期間が締め済みか、訂正を認められているか、取消・訂正の方法も未確認です。8,000円という草案額だけで、計上先や差額仕訳、期間を決めることはできません。

未登録の段階：元の版と、残っている候補をそろえる

会計側がまだ候補の段階なら、元の訂正をどう取り込み直すか、古い候補をどう区別するかを確認します。元だけが新しい版になり、会計側で古い候補をそのまま登録しないよう、対象と版を照合する条件が必要です。候補を変更・除外できる範囲と権限は製品で確かめます。

既登録の段階：訂正の記録と元の対応を残す

既に登録や計上がある場合は、会社の経理が適用するルールと製品仕様に沿って、取消、反対の記録、訂正など必要な方法を判断します。どの方法が許されるかをこの記事から一律に決めるものではありません。元の記録、訂正後の記録、理由、実施者と時点が追え、後から同じ元取引の状況を説明できる条件を求めます。

販売側の返品や請求取消と、会計側の取消・返金・入金消込は同じ操作ではありません。今回の範囲外なら、どの担当へ何を渡し、どの結果を確認して連携側の対応を終えるかを定めます。返金や支払を、記録の訂正だけで実施済みにしないでください。

締め後：期間と権限を確かめ、経理が扱いを判断する

遅れて届いた情報や締め後に見つかった誤りについて、対象の期間がどの状態で、誰が訂正の可否と反映先を判断するかを決めます。ロックを外す操作や別期間へ入れる処理を、連携担当が独断で行う運用にはしません。経理の判断を受け、連携側で止める条件、必要な権限、残す履歴を製品担当と対応させます。

権限・履歴・移行と、停止時の仕事を決める

連携を作る担当と、金額・期間・科目を判断する経理の役割を分け、例外時にどちらへ戻るかを決めます。日々の監視、月末の照合、マスター変更、製品更新の後まで、誰が何を見るかを具体化してください。

必要な人だけが、必要な情報と操作へ届くようにする

元を確認する人、対応表を変える人、会計側へ登録・訂正する人、結果を照合する人について、権限と確認の分担を経理・情報管理担当と決めます。共通の強い管理者権限をすべての連携に使う前提にせず、対象製品が使える権限、変更の確認方法、利用停止時の扱いを尋ねます。

取引先情報、担当者名、金額など、渡す必要がある情報と、問い合わせやログへ出す範囲を分けます。実データや認証情報を説明用の画像・試験資料に載せる必要はありません。履歴の保管範囲、確認できる担当、保管・削除の条件は、適用する社内規程や要件に沿って確認します。

監視するのは、通信エラーだけでなく未処理と照合差

未送信、受付待ち、検査で保留、登録待ち、照合差など、自社で必要な状態を追えるようにします。件数と最終処理時点、対象の期間や元取引へ戻る方法、通知先、調査する担当と期限を定めます。「エラー0」でも、送るべき対象が選ばれていなければ漏れを発見できないため、元側の送信対象とも合わせます。

月末や大量処理の場面では、対象量、利用する時間帯、会計側の処理待ち、完了が必要な期限を示します。架空の2明細から本番性能は推測できません。代表的な条件で処理と照合が終わるかを試し、間に合わない場合の通知・保留・業務側の扱いまで相談します。

移行と並行運用では、旧・新の境界を先に決める

切替の基準時点、取り込む期間と対象、旧側の未処理や訂正、新側で処理済みの範囲を対応させます。過去の情報を確認用に移すのか、会計処理の対象として入れるのかも分けます。既に帳簿へ入っている取引を、新しい連携から重ねない条件が必要です。

旧・新を比べる並行運用では、比較のための処理が本番の二重登録にならない場所と権限を定めます。同じ対象、対応表、期間、金額の範囲をそろえ、差を調べてから切替条件を判断します。開始後に問題があったときも、処理済みの記録と残りを確認せず旧方式へ戻すのではなく、戻せる範囲と照合の手順を用意します。

停止中の仮記録を、再開後に二重登録しない

停止中にどの仕事を続け、どの登録を待つかを経理と決めます。仮に別の記録へ残すなら、元取引・版と処理状況を追い、再開後に送信途中の分や既登録分と照合する必要があります。手入力した分と自動連携が重なる条件を試し、誰が再開範囲を決めるかも明らかにします。

同じ取引と例外で、回答と実結果を確かめる

候補には同じ元取引と必要な例外を示し、標準機能・設定・追加対応・人に残る仕事を分けて答えてもらいます。「会計連携対応」の有無だけでなく、同じ番号から受け側の記録と訂正履歴へ戻れるかを確かめます。

• 標準機能で合う回答：対象の製品・版・利用条件、使う項目、状態、設定、制限と確認記録を特定します。画面の説明だけでなく、一件の対応結果を確認します。
• 設定・追加開発が必要な回答：不足する対応、実施する担当、変更・保守の範囲、期間と費用を分けます。製品更新や項目追加で、どの確認をやり直すかも含めます。
• 人が確認する運用を残す回答：何を、どの件数やタイミングで、誰が照合するかを業務側と判断します。「経理が何とかする」で終えず、差の調査へ戻れる情報があるかを確認します。
• 必須条件に合わない・分からない回答：どの取引や判断が成立しないかを明らかにし、追加確認、範囲変更、候補の見直しへ戻します。方式の便利さで、訂正や照合ができない不足を相殺しません。

試す前に、同じ入力と期待する結果をそろえる

1. 前提を決める。試験を行える場所と権限、対象製品の版と設定、会計側の期間・コードの状態、説明用の取引をそろえます。実際の帳簿や支払へ無断で反映する試験ではありません。
2. 期待する記録を決める。元番号・明細・版と、会計側で確認する記録、金額・期間・状態、保留の理由を経理と定めます。まだ決まっていない科目や税の扱いを、草案額から補いません。
3. 通常の対象を通して照合する。対象選択から受付・候補・登録・反映のうち今回含める範囲を通し、元と先の対応、内訳、結果を確かめます。完了表示だけで終えません。
4. 必要な例外を同じ基準で確かめる。未登録コード、期間違い、一部保留、同じ対象の再送、応答が途切れた結果不明、元の訂正、締め後の入力などを選びます。どこで止まり、何が残り、誰の判断で次へ進むかを確認します。
5. 修正後に影響する範囲を照合する。対象選択、項目の意味、変換、処理状態、訂正の扱いのうち、差の原因へ戻します。変更後は同じ前提で結果を確かめ、元と先の対応を残します。

結果不明の試験では、同じ取引をもう一度送って終わったことだけで判断しません。元の試行がどこまで処理され、重複がどのように扱われ、必要な残りだけを進められるかを確認します。訂正の試験でも、訂正前の記録が追え、適切な状態と期間で扱われることを、経理が決めた期待と照合します。

まとめ：一つの取引を、会計側の確認まで追う

会計ソフトと業務システムをつなぐ前には、元の取引番号・明細・版、金額やコードの意味、日付と期間、送る条件をそろえます。元の一件と会計側の行数が同じとは限らないため、集計しても内訳へ戻れる方法を決めます。

送信、受付、仕訳候補、登録、計上、照合を分け、どの記録で確認するかを製品と経理の担当へ結び付けます。結果不明なら再送の前に所在を調べ、訂正では元と会計側の状態、締めの状況を確認します。権限・履歴・移行・停止時を含め、同じ取引と例外で期待と実結果を照合してください。