相談事例 /
首都圏（東京・神奈川）
焼肉・居酒屋14店舗のPOSと会計freeeが連携せず月末に経理が泊まる ─ Airレジ・スマレジ混在のまま中間レイヤーでつなぎ、突合20時間を2時間未満に縮めた事例
課題
AirレジとスマレジとFC由来ターミナルが混在し、日次売上はCSVを本部Excelへ手入力。現金・クレジット・PayPay・楽天ペイ・Squareの入金と売上の突合に毎月20時間近くを費やしていた。会計freeeへの仕訳も手入力で、店内10%／テイクアウト8%の軽減税率の区分誤りが月平均14件。決算期に税理士から修正指摘が続き、月末は経理3名が締めに張り付く状態だった。
解決策
POSの全店統一を急がず、バラバラのPOSと会計freeeを結ぶ中間レイヤーを構築。スマレジ・プラットフォームAPIとAirレジの日次CSV、PayPay／楽天ペイ／Squareの入金明細を取り込み、店舗・日付・決済手段をキーに売上と突合。合わない差異だけを翌朝に未消込リストとして出力。商品マスタの店内／テイクアウト×8%／10%を再マッピングし、freee APIへ日次仕訳を自動投入。日次バッチはCloudflare Workers Cron＋小型VPSで運用。
成果
月末の突合作業は20時間から2時間未満へ。税区分の誤りは月14件からほぼゼロ。経理3名のうち1名を締め作業から予算分析・店舗支援へ再配置できた。初期費用180万円、月額運用は決済連携の保守込みで4万円台。FC由来2店舗のスマレジ統一が終われば、最後に残る手作業も消える見込み。
東京と神奈川で焼肉・大衆居酒屋を中心に14店舗を構える飲食チェーンからの相談でした。月商はおよそ2.1億円、社員とアルバイトを合わせて約320名。本部の経理は3名で、この3名が14店舗ぶんの日次売上と決済の突合を抱えていました。
最初の電話で出てきた言葉は「月末になると経理が会社に泊まる」。誇張ではありませんでした。月次の締めで、現金・クレジット・QR決済の入金が売上とどうしても合わない。その差異を一件ずつ追う作業に、毎月20時間近くを溶かしていたのです。
問題の根は、POSがバラバラだったことにあります。古い店舗はAirレジ、後から出した店舗はスマレジ、フランチャイズから買い取った2店舗にいたっては別系統のターミナルが残っていました。日次の売上はそれぞれの管理画面からCSVを落とし、本部のExcelに手入力。決済はPayPay、楽天ペイ、Squareのクレジット、そして現金。入金サイクルがすべて違うため、「いつの売上がいつ入金されたか」を人間が記憶と勘で紐づけていました。
会計はfreeeでした。ただ、POSからfreeeへは一切連携しておらず、日次の仕訳もExcelを見ながらの手入力です。ここで軽減税率が牙を剝きます。店内飲食は10%、テイクアウトは8%。同じ唐揚げでも提供形態で税区分が変わるのに、POSの商品マスタ側でその区別が徹底されていない店舗があり、税区分の誤りが月平均14件。決算期に税理士から指摘が入り、修正仕訳でまた時間が消えていく悪循環でした。
依頼の本音は「POSを全部スマレジに統一したい、でも今は無理」。繁忙期を抱える14店舗のレジを一斉に入れ替えるのは、現場が止まるリスクが高すぎます。提案したのは、POSの統一を急がず、バラバラのまま会計につなぐ中間レイヤーを挟む構成でした。
スマレジは「スマレジ・プラットフォームAPI」で日次の売上明細が取れます。Airレジは公式APIが弱いため、管理画面の日次CSVを自動取得する経路にしました。フランチャイズ由来のターミナルだけはどうにもならず、ここは正直に「自動化を諦め、月内にスマレジへ寄せましょう」と切りました。何でも自動化しようとして一番厄介な1店舗に全体の納期を引っ張られる──過去に何度もやらかした失敗で、今回は最初から切り分けています。
決済側は、PayPay for Business、楽天ペイ、Squareそれぞれの入金明細を取り込み、店舗・日付・決済手段をキーに売上と突合する仕組みにしました。突合できなかった差異だけを「未消込リスト」として翌朝に吐き出す。経理が見るのは合わない数件だけになり、全件を目視する必要が消えます。
立ち上げ初週に、ある駅前店で現金が3,200円合わないというアラートが出ました。追ってみると、釣銭準備金の補充をレジ操作を介さずに済ませていたのが原因で、システムの不具合ではありません。むしろ、これまで月末まで埋もれていた現場のオペレーションの綻びが、翌朝に見えるようになっただけのことです。突合の自動化は、経理の手間を消すだけでなく、店舗の運用の穴を翌日に可視化する装置にもなりました。導入の副産物として、現金の取り扱いルールを全店で引き締める動きにつながっています。
税区分は、POSの商品マスタを棚卸しして、店内／テイクアウトの提供形態と8%／10%を商品単位でマッピングし直しました。地味ですが、ここを正さないと下流の仕訳がいくら自動でも誤りが流れ続けます。整えたマスタをもとに、freeeのAPIへ日次仕訳を自動投入する形にしています。
freee側の仕訳設計にも踏み込みました。決済手段ごとに売掛金の補助科目を分け、PayPayや楽天ペイの決済手数料は入金時に支払手数料として落とす。売上は税区分（課税売上10%と軽減8%）で行を割り、現金は当日、キャッシュレスは入金日基準で計上する。これを店舗ごとの締め時刻に合わせて自動で組み立てています。手入力では事実上不可能だった粒度を、毎日積み上がる形で確保しました。月次でまとめて辻褄を合わせる運用から、日次で正しく積む運用へ重心を移したわけです。
「スマレジにもfreee連携アプリがあるのに、なぜ自前で作るのか」とは当然問われました。純正連携は単独店・単一POSなら十分です。ただ今回は、Airレジが混ざり、決済が3社にまたがり、店内とテイクアウトで税区分が割れる。純正アプリの想定を一つ外れると、結局そこから手作業が再発します。全店がスマレジに揃った将来は純正へ寄せる前提で、それまでの数ヶ月を埋める中継ぎとして中間レイヤーを置いた、という整理です。最初から恒久設備のつもりでは作っていません。
実装は大げさにしていません。日次バッチはCloudflare WorkersのCron Triggersで起動し、重い突合処理だけ月額3,000円台の小さなVPS上のワーカーで回す。データはMySQLに正規化して持ち、freeeへはレート制限を踏まないよう夜間にまとめて投入します。新しい基幹システムを建てる話ではなく、既存のPOSと会計の「あいだ」を埋めるだけの構成です。
移行は段階的に進めました。まずスマレジ4店舗で2週間まわして突合精度を確認し、そこからAirレジ店舗、決済連携、税区分の順で広げています。全体で約7週間。途中、楽天ペイの入金明細CSVの仕様が一部変わっていて取り込みが2日止まりましたが、フォーマット差分を吸収するパーサに直して復旧しました。外部仕様は黙って変わる、という前提で作っておいたのが効いています。
結果として、月末の突合作業は20時間から2時間を切る水準まで縮みました。税区分の誤りは月14件からほぼゼロへ。経理3名のうち1名が、締め作業から店舗支援や予算分析へ時間を回せるようになっています。初期費用は180万円、月額の運用は決済連携の保守を含めて4万円台。フランチャイズ2店舗のスマレジ統一が終われば、最後の手作業も消えます。
最後に、正解だったと思っている判断をひとつ。「POSをまず統一してから会計につなぐ」という王道を、今回はあえて採りませんでした。統一を前提にすると、現場が止まる繁忙期を避けるうちに何ヶ月も着手できない。先に会計連携の痛みを止め、統一はその裏で淡々と進める。順序を入れ替えただけですが、経理が泊まらなくなるまでの時間が半年は縮みました。
最初の電話で出てきた言葉は「月末になると経理が会社に泊まる」。誇張ではありませんでした。月次の締めで、現金・クレジット・QR決済の入金が売上とどうしても合わない。その差異を一件ずつ追う作業に、毎月20時間近くを溶かしていたのです。
問題の根は、POSがバラバラだったことにあります。古い店舗はAirレジ、後から出した店舗はスマレジ、フランチャイズから買い取った2店舗にいたっては別系統のターミナルが残っていました。日次の売上はそれぞれの管理画面からCSVを落とし、本部のExcelに手入力。決済はPayPay、楽天ペイ、Squareのクレジット、そして現金。入金サイクルがすべて違うため、「いつの売上がいつ入金されたか」を人間が記憶と勘で紐づけていました。
会計はfreeeでした。ただ、POSからfreeeへは一切連携しておらず、日次の仕訳もExcelを見ながらの手入力です。ここで軽減税率が牙を剝きます。店内飲食は10%、テイクアウトは8%。同じ唐揚げでも提供形態で税区分が変わるのに、POSの商品マスタ側でその区別が徹底されていない店舗があり、税区分の誤りが月平均14件。決算期に税理士から指摘が入り、修正仕訳でまた時間が消えていく悪循環でした。
依頼の本音は「POSを全部スマレジに統一したい、でも今は無理」。繁忙期を抱える14店舗のレジを一斉に入れ替えるのは、現場が止まるリスクが高すぎます。提案したのは、POSの統一を急がず、バラバラのまま会計につなぐ中間レイヤーを挟む構成でした。
スマレジは「スマレジ・プラットフォームAPI」で日次の売上明細が取れます。Airレジは公式APIが弱いため、管理画面の日次CSVを自動取得する経路にしました。フランチャイズ由来のターミナルだけはどうにもならず、ここは正直に「自動化を諦め、月内にスマレジへ寄せましょう」と切りました。何でも自動化しようとして一番厄介な1店舗に全体の納期を引っ張られる──過去に何度もやらかした失敗で、今回は最初から切り分けています。
決済側は、PayPay for Business、楽天ペイ、Squareそれぞれの入金明細を取り込み、店舗・日付・決済手段をキーに売上と突合する仕組みにしました。突合できなかった差異だけを「未消込リスト」として翌朝に吐き出す。経理が見るのは合わない数件だけになり、全件を目視する必要が消えます。
立ち上げ初週に、ある駅前店で現金が3,200円合わないというアラートが出ました。追ってみると、釣銭準備金の補充をレジ操作を介さずに済ませていたのが原因で、システムの不具合ではありません。むしろ、これまで月末まで埋もれていた現場のオペレーションの綻びが、翌朝に見えるようになっただけのことです。突合の自動化は、経理の手間を消すだけでなく、店舗の運用の穴を翌日に可視化する装置にもなりました。導入の副産物として、現金の取り扱いルールを全店で引き締める動きにつながっています。
税区分は、POSの商品マスタを棚卸しして、店内／テイクアウトの提供形態と8%／10%を商品単位でマッピングし直しました。地味ですが、ここを正さないと下流の仕訳がいくら自動でも誤りが流れ続けます。整えたマスタをもとに、freeeのAPIへ日次仕訳を自動投入する形にしています。
freee側の仕訳設計にも踏み込みました。決済手段ごとに売掛金の補助科目を分け、PayPayや楽天ペイの決済手数料は入金時に支払手数料として落とす。売上は税区分（課税売上10%と軽減8%）で行を割り、現金は当日、キャッシュレスは入金日基準で計上する。これを店舗ごとの締め時刻に合わせて自動で組み立てています。手入力では事実上不可能だった粒度を、毎日積み上がる形で確保しました。月次でまとめて辻褄を合わせる運用から、日次で正しく積む運用へ重心を移したわけです。
「スマレジにもfreee連携アプリがあるのに、なぜ自前で作るのか」とは当然問われました。純正連携は単独店・単一POSなら十分です。ただ今回は、Airレジが混ざり、決済が3社にまたがり、店内とテイクアウトで税区分が割れる。純正アプリの想定を一つ外れると、結局そこから手作業が再発します。全店がスマレジに揃った将来は純正へ寄せる前提で、それまでの数ヶ月を埋める中継ぎとして中間レイヤーを置いた、という整理です。最初から恒久設備のつもりでは作っていません。
実装は大げさにしていません。日次バッチはCloudflare WorkersのCron Triggersで起動し、重い突合処理だけ月額3,000円台の小さなVPS上のワーカーで回す。データはMySQLに正規化して持ち、freeeへはレート制限を踏まないよう夜間にまとめて投入します。新しい基幹システムを建てる話ではなく、既存のPOSと会計の「あいだ」を埋めるだけの構成です。
移行は段階的に進めました。まずスマレジ4店舗で2週間まわして突合精度を確認し、そこからAirレジ店舗、決済連携、税区分の順で広げています。全体で約7週間。途中、楽天ペイの入金明細CSVの仕様が一部変わっていて取り込みが2日止まりましたが、フォーマット差分を吸収するパーサに直して復旧しました。外部仕様は黙って変わる、という前提で作っておいたのが効いています。
結果として、月末の突合作業は20時間から2時間を切る水準まで縮みました。税区分の誤りは月14件からほぼゼロへ。経理3名のうち1名が、締め作業から店舗支援や予算分析へ時間を回せるようになっています。初期費用は180万円、月額の運用は決済連携の保守を含めて4万円台。フランチャイズ2店舗のスマレジ統一が終われば、最後の手作業も消えます。
最後に、正解だったと思っている判断をひとつ。「POSをまず統一してから会計につなぐ」という王道を、今回はあえて採りませんでした。統一を前提にすると、現場が止まる繁忙期を避けるうちに何ヶ月も着手できない。先に会計連携の痛みを止め、統一はその裏で淡々と進める。順序を入れ替えただけですが、経理が泊まらなくなるまでの時間が半年は縮みました。