税込・税抜(内税)・税抜(別記)——MFに仕訳を入れると何が変わるか

消費税の経理方式は「税込か税抜か」の二択だと思われがちですが、会計ソフトの設定としては三択です。 そして同じ取引・同じ税区分を入れても、方式によって帳簿に乗る数字も、API に送る金額の意味も変わります。 この記事はマネーフォワード クラウド会計を実際に3方式で動かして、画面の設定値・API のパラメータ・端数処理の挙動まで測った記録です。

検証日 2026-09-13 ／ マネーフォワード クラウド会計（法人・原則課税・個別対応方式）／ 公開 API v3

経理方式は「消費税をどこに置くか」の3択

消費税を預かる事業者は、預かった税を売上に含めたまま処理するか、売上から抜いて別の勘定に置くかを選べます。 抜く場合はさらに、ソフトに自動で抜かせるか、自分で仕訳に書くかに分かれます。ここで3択になります。

税込 11,000 円（本体 10,000 ＋ 消費税 1,000）の売上を、それぞれの方式で入れたときに帳簿に何が乗るかを並べると次のようになります。

MF ではどこで切り替えるか

「事業者」の設定画面（/offices/edit）の中にあります。フォームのフィールド名と値は次のとおりです。

もうひとつ実務上の注意として、方式を切り替えると、その事業者の全仕訳の update_time が切替時刻に書き換わります。 保存されている金額（本体・税額）は1円も動きませんが、内部で税額を計算し直しているためです。 更新日時を監査証跡として使っている場合は影響を受けます。

API に送る値・返る値はどう変わるか

ここからが本題です。マネーフォワードの公開 API v3（POST /api/v3/journals など）で仕訳を入れるとき、 value に何を入れるべきかは方式によって変わります。しかも送るときと受け取るときで意味が違います。

借方 仕入高（課仕 10%）／貸方 売上高（課売 10%）の1行仕訳に 22,000 を送ったときの実測です。

この表から読み取れることは3つあります。

1. 税込経理でも GET は税抜を返す

直感に反しますが、API の表現は経理方式に連動していません。税込経理の事業者でも、GET の value は本体価額で、 消費税は tax_value に別出しされます。変わるのは帳簿（試算表・P/L・B/S）の見え方だけです。 「税込経理の顧問先なら value が税込で返るはず」という前提でコードを書くと、その事業者だけ金額が合わなくなります。

2. POST / PUT のレスポンスは「税込ビュー」

登録直後に返ってくる JSON の value は、送った値がそのまま返ってきたように見えます。 実体は value + tax_value の税込表示で、同じ仕訳を GET し直すと別の数字（税抜）になります。

POST value=22,000  →  レスポンス value=22,000 / tax_value=2,000
その直後の GET     →  value=20,000 / tax_value=2,000

往復テストの基準にレスポンスを使うと、比較対象がずれてテストが空振りします（実際に1回やりました）。 基準にするのは必ず GET のほうです。

3. 別記だけが素通し

税抜(別記) では自動分離が起きません。tax_value は常に 0 で、送った value がそのまま本体として保存されます。 税区分（tax_id）は消費税申告の集計のために記録されますが、金額は1円も動かされません。

貸借の判定に使う金額も変わる

借方 普通預金（対象外）11,000 ／ 貸方 売上高（課売 10%）10,000 を送るとどうなるか。

内税の場合、貸方に 10,000 と書いても税込 10,000 として扱われるので、借方 11,000 と釣り合いません。 内税で入れるなら貸方も 11,000（税込）を送ります。MF が受け取ったあと 10,000 ＋ 1,000 に割り戻します。

別記で同じ取引を入れるなら、税額を自分で1行足します。

"branches": [
  {
    "remark": "本体",
    "debitor":  {"account_id": "<普通預金>", "tax_id": "<対象外>", "value": 11000},
    "creditor": {"account_id": "<売上高>", "tax_id": "<課売10%>", "value": 10000}
  },
  {
    "remark": "消費税",
    "creditor": {"account_id": "<仮受消費税>", "tax_id": "<対象外>", "value": 1000}
  }
]

これは 201 で通り、GET すると3行とも tax_value: 0、value は 11,000 ／ 10,000 ／ 1,000 になります。

端数処理は「割戻し・切り捨て」がどう効くか

検証した事業者の設定は、売上・仕入とも round_down（切り捨て）＋ rebate（割戻し）でした。 このとき、税込 20,001 円を送ると次のように分解されます。

税額 = floor(20,001 × 10 ÷ 110) = 1,818
本体 = 20,001 − 1,818          = 18,183

実測も value: 18,183 / tax_value: 1,818 でした。税額を先に計算して切り捨て、残りを本体にするという順序です。 本体を先に丸める実装（20,001 ÷ 1.1 = 18,182）とは1円ずれるので、自前で検算するコードを書くときは順序に注意してください。

GET した仕訳を PUT で書き戻すときの落とし穴

既存の仕訳のメモだけを書き換えたいとき、PUT /api/v3/journals/{id} は省略したフィールドを消すので、 GET した内容を PUT の形に写して丸ごと送り返すことになります。ここで、GET は税抜・PUT は税込という非対称が効いてきます。

本体 10,000 ＋ 税 1,000（税込 11,000）で保存されている行に、いろいろな値を PUT してみた結果です。

つまり PUT の value は税込なのですが、保存されている税抜額と同じ値が来たときだけ「変更なし」として無視されるという挙動があります。 そのため「GET した税抜をそのまま PUT に流す」実装は、仕様どおりなら金額が税率ぶん縮むはずなのに、たまたま壊れません。

これは仕様ではなく実装の副作用に見えるので、書き戻すときは value + tax_value（＝税込）を送るのが正しい形です。 別記の行は tax_value が 0 なので、この式は3方式すべてで正しく動きます—— 経理方式を判定しなくても、tax_value を足すだけでよいということです。

// GET した行 → PUT に送る金額
const putValue = (line) => line.value + (line.tax_value ?? 0)

帳簿の数字はどれだけ変わるか（実測）

同じ4本の仕訳（売上 3本・売上と仕入 1本、いずれも税込ベースで 10% 課税）を入れたまま、経理方式だけを切り替えて推移表を読み直した結果です。

税抜(内税) だけ、売上高が 4,909 円小さくなり、その分が仮受消費税として B/S に残ります。 この「預かった税が期末に負債として残り、翌期に出ていく」ズレが、キャッシュ・フローを読むうえでの要所です。 損益には出てこないのに現金は動くからです。

どれを選ぶか

実務では税抜(内税)が既定と考えて差し支えありません。入力は税込額を打つだけで済み、 売上・費用が税抜で並ぶので利益率の比較が素直になり、仮受・仮払消費税の残高がそのまま納税額の目安になります。

• 税込：免税事業者や、消費税の論点を扱わない教材・シミュレーションで使う。P/L の数字が「実際に動いた金額」と一致するのが利点
• 税抜(内税)：課税事業者の既定。ソフトに任せられるぶん入力事故が少ない
• 税抜(別記)：本体と税を明示的に管理したい、あるいは外部システムが既に税額を持っている場合。ソフトの自動計算が効かないので、入れる側の設計次第で簡単に狂う

なお、税区分を全行「対象外」で入力したデータは、どの方式に切り替えても金額が1円も動きません。 消費税を扱わない前提の教材データを作るときは、方式をいじるよりも税区分を明示的に「対象外」にするほうが安全です。 税区分を省略すると、MF は勘定科目の既定税区分（売上高なら課売 10%）を自動で当ててしまい、税抜経理では金額が割り戻されてしまいます。

まとめ

• 経理方式は term[include_tax_id]（1=税込 / 2=税抜(別記) / 3=税抜(内税)）。年度別ではなく事業者全体の設定
• 公開 API の value は POST/PUT では税込、GET では税抜。税込経理でも GET は税抜
• 例外は税抜(別記)だけ。tax_value は常に 0 で、送った額面がそのまま保存される
• 貸借の判定は、内税・税込なら税込ベース。別記なら額面ベース
• 書き戻しは value + tax_value を送れば3方式すべてで正しい
• 端数は「税額を割戻しで計算して丸め、残りを本体にする」順序