架空の伝票C41は、10.6円の明細が2行ある計算教材です。各行の数量は1という設定にします。経理担当は、両システムで同じ2行を計算しているかを最初に確認します。

単価の版、数量、値引き、対象外の明細が違う場合は、丸めだけの差ではありません。元データと対象範囲を並べ、差が始まった箇所を確認します。合計の1円差から原因を断定しません。

画面に10.6円と見えていても、内部には別の桁まで保存されている場合があります。開発担当は保存した原値と表示の丸めを分けて確認し、比較表へ記します。

この章の根拠：出典2出典3

この教材は正の数を1円単位に四捨五入する設定です。各明細10.6円を11円へ丸めてから足すと、11円＋11円＝22円です。明細で丸めず10.6円＋10.6円＝21.2円を足してから丸めると21円です。

丸め方が同じでも、計算のどこで丸めたかが違います。経理と開発は、単価、数量を掛けた明細、明細の合計のどの段階で丸めるかを比較表へ記します。

どちらを正規のルールにするかは、この例の小さい方や大きい方から決まりません。既存の約束、帳票、社内の経理ルールを責任者が確認します。対象となる費用範囲も同じにします。

この章の根拠：出典2

画面の桁を整数へ減らすことと、保存値を整数へ変えることは違います。原値10.6円を保存し画面だけ11円と表示した場合、再計算の値はどちらを使うかを確認します。

JSONは、データを項目名と値などで表して受け渡す形式です。JSONなどの形式で数値を渡せても、受信側の実装が扱う桁や精度には制約があります。RFC8259はその制約の考慮を示します。経理の丸め位置や会計上の正規ルールを指定するものではありません。

開発担当は、必要な小数の範囲と最大値、入力から出力までの計算方式を確認します。文字列で渡す候補も、受信側で数値化する条件とセットにして検証します。型名だけで精度が保たれるとは扱いません。

この章の根拠：出典1出典3

経理責任者は整数の明細、10.6円の例、丸めの境界となる値、複数明細を用意します。取消や負の調整額を扱う業務なら、そのルールも別に確認例へ入れます。正の例だけで全ルールが確認済みとはしません。

比較表へ原値、途中の明細、合計前、表示額を残します。両システムの画面だけを比べるより、差が出た段階を探しやすくなります。期待する結果は経理責任者が確認します。

税や外貨などの別計算がある場合は、それぞれの責任者のルールへ切り分けます。この教材の四捨五入をそのまま全費用へ適用せず、対象の計算に必要な確認を指定します。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典2

開発担当が設定を変更したら、同じC41と他の確認例で結果を照合します。合計が偶然一致しただけでなく、正規ルールと途中計算が一致することを経理が確認します。

過去の帳票を再計算するかは、経理責任者が対象と必要性を判断します。設定を変更しただけで既存の請求が正されたとは扱いません。対外的な対応が必要な記録は、正規の担当へ渡します。

差を手動の調整額で合わせた記録があるなら、その根拠も確認します。調整を除いた値と変更後の値を混ぜず、旧ルールと新ルールの適用範囲を保存します。

この章の根拠：出典2出典3

C41の10.6円が2明細ある例では、明細ごとの四捨五入は22円、合計後は21円でした。同じ丸め方でも位置が違うと差が出ます。

経理責任者が正規のルールを確認し、開発担当が保存値、途中計算、表示と受渡しを照合します。合計だけを手で合わせるのでは、原因が残ります。

計算比較表の記入メモへ、確認例と新旧の適用範囲を記してください。過去の帳票の扱いは別に判断し、どの条件で金額が一致するかを説明できる資料にします。

この章の根拠：出典1出典2出典3