支払予定表で手で入れるのは、取引先ごとの締め日と支払サイトだけでいい。支払日は式で出る。
11件の請求で試した。2件が土日に当たって前営業日にずれ、そのうち1件は月をまたいだ。予定表に11月と書いてあった1,460,000円が、実際には10月30日に出ていく。
以下の計算は、2026年9月21日にMicrosoft 365のExcel(バージョン16)で行った。祝日は内閣府の一覧を使った。取引条件と金額は式を確かめるために作った架空のものだ。
取引先ごとに入れるのは4つの数字
取引条件を数字で持たせる。文字で「月末締め翌月末払い」と書くと式で使えない。
締め日は日にちを入れる。月末なら0にする。支払の月差は、締め日の何か月後に払うか。翌月なら1、翌々月なら2、当月なら0。支払日も日にちで、月末なら0。最後に支払方法と、手形なら手形のサイト日数。
この4つがあれば、あとは全部式で出る。取引先の一覧を別シートに持って、請求の行からはVLOOKUPで引く。
条件が変わったときに直すのは一覧の1行だけになる。予定表の各行に条件を書いていると、変更のたびに全部の行を探すことになる。
締め日を出す式
請求日がどの締め期間に入るかを決める。
=IF(締め日=0,EOMONTH(請求日,0),
IF(DAY(請求日)<=締め日,DATE(YEAR(請求日),MONTH(請求日),締め日),
DATE(YEAR(請求日),MONTH(請求日)+1,締め日)))
月末締めならEOMONTHで当月の末日が出る。20日締めなら、請求日が20日以前ならその月の20日、21日以降なら翌月の20日になる。
DATEの月に+1を足す書き方は、12月でも翌年1月に繰り上がる。年をまたぐ処理を自分で書かなくていい。
手元の例では、5月19日の請求が5月20日締め、5月25日の請求が6月20日締めになった。6日違うだけで、締めが1か月ずれる。
支払日を出す式
締め日に支払サイトを足す。
=IF(支払日=0,EOMONTH(締め日,月差),
DATE(YEAR(EDATE(締め日,月差)),MONTH(EDATE(締め日,月差)),支払日))
月末払いならEOMONTHに月差を渡すだけだ。5月31日締めの翌月末払いなら6月30日になる。
日にち指定の払いは、EDATEで月を進めてから、その年と月に日にちを組み合わせる。5月20日締めの翌月10日払いなら6月10日だ。
15日締め当月末払いという条件もある。月差が0なので、5月15日締めの支払日は5月31日になる。締めてから2週間で払う条件だ。
土日祝に当たると前営業日になる
暦の上の支払日がそのまま振込日になるとは限らない。土日祝に当たったら、多くの約定で前営業日に繰り上がる。
=WORKDAY(支払日+1,-1,祝日!$A:$A)
WORKDAYに-1を渡すと、その日から1営業日前を返す。支払日そのものが営業日なら動かないように、いったん翌日を起点にしてから1営業日戻す。この+1がないと、営業日の支払日まで前にずれる。
祝日の一覧を別シートに持たせる作り方は祝日を判定する記事に書いた。内閣府のCSVをそのまま使える。
11件のうち2件がずれた。15日締め当月末払いの取引先で、5月31日が日曜だったので5月29日の金曜になった。2日前倒しだ。
11月のはずが、10月に出ていった
もう1件のずれが問題だった。
月末締めで翌々月1日払いという条件の取引先がいる。9月30日締めなので、暦の上の支払日は11月1日になる。ところが2026年11月1日は日曜だ。前営業日は10月30日の金曜になる。
月が変わる。予定表を月で集計すると、11月の欄が0円、10月の欄に1,460,000円が入る。条件だけ見て11月の支出と見込んでいると、10月の資金繰りが足りなくなる。
月をまたいだかどうかは式で出せる。
=SUMPRODUCT(--(MONTH(実際の支払日)<>MONTH(暦の支払日)))
11件で1件と出た。毎月これを見て、1以上なら該当の行を確かめる。翌月1日払い、翌月5日払いのように、月の頭に支払日がある取引先で起きやすい。
手形は請求から144日後に落ちた
手形の期日は、振出日にサイトの日数を足す。振出日は振込の支払日と同じ日になる。
=IF(方法="手形",WORKDAY(実際の支払日+サイト日数+1,-1,祝日!$A:$A),"")
サイト90日の取引先で計算した。5月7日の請求が5月31日締め、6月30日が支払日で手形の振出日。そこから90日で9月28日が期日になる。
請求から現金が出るまで144日ある。4か月半だ。同じ表の振込の取引先は請求から平均41日で出ていくので、3.5倍の差になる。
手形の行は、支払日の月ではなく期日の月で資金繰りに入れる。ここを間違えると、6月に3,400,000円が出ていく前提で計算してしまう。実際に口座から引かれるのは9月だ。
月ごとにいくら出ていくか
集計はSUMIFSで足りる。条件に使うのは暦の支払日ではなく、実際の支払日の列にする。
=SUMIFS($金額,$実際の支払日,">="&DATE(2026,6,1),$実際の支払日,"<="&DATE(2026,6,30))
手元の例では6月に8,550,000円、7月に3,170,000円と出た。6月に集中しているのは、月末締め翌月末払いの取引先が多いからだ。
月末に固まるなら、入金の予定と突き合わせる。売掛の回収が翌月20日で、支払が翌月末なら10日の余裕がある。回収が翌々月なら足りない。この差が資金繰りの実体になる。
月次の作業に組み込む形は月次の締めの記事と同じで、第何営業日に見るかを決めておく。
入金予定と並べて、月末の残高を出す
支払予定表だけでは資金繰りにならない。入金の予定と並べて、月末にいくら残るかまで出す。
列は、月、月初残高、入金、支払、月末残高の5つ。支払の欄には、上で出した実際の支払日で集計した額を入れる。
月初残高: =前の月の月末残高
月末残高: =月初残高+入金-支払
4か月分で計算した。月初の残高を4,200,000円として、6月は入金9,800,000円と支払8,550,000円で月末5,450,000円。7月は9,480,000円、8月は15,240,000円、9月は19,940,000円になった。
いちばん少ないのは6月末の5,450,000円だ。支払が集中する月がそのまま底になる。
=MIN($月末残高の範囲)
=INDEX($月の範囲,MATCH(MIN($月末残高の範囲),$月末残高の範囲,0))
この2本で、底の額と底の月が出る。借入や支払条件の交渉を考えるのは、この月に向けてになる。
手形を振出の月で数えていたら、6月末の残高は2,050,000円と出る。正しくは5,450,000円で、3,400,000円の差だ。底の月の判断が変わる額になる。
踏んだ失敗
暦の支払日で集計していたことがある。営業日のずれを列には出していたのに、SUMIFSの条件が暦の列を向いていた。上の例でいえば11月に1,460,000円が立ったままになる。列を作っただけで、使う列を切り替えていなかった。
手形を支払日の月で数えていたこともある。6月の支出が3,400,000円多く見え、資金が足りないと判断して借入の相談をした。実際には9月の話だった。方法の列で分けるようにした。
取引条件を予定表の行に直接書いていた時期もある。支払サイトが変わった取引先の行を、過去の分まで書き換えてしまった。条件は取引先の一覧に置いて、予定表からは引くだけにする。
WORKDAYの+1を入れ忘れたこともある。支払日が営業日なのに1日前にずれて、全部の行が1日早く出た。合計は変わらないので気づきにくい。月をまたぐ行で初めておかしいと分かった。
支払の記録そのものを式で確かめる話は経費精算のチェックの記事に書いた。予定と実績の突き合わせも同じ考え方でできる。
確認していないこと
振込手数料の負担をどちらが持つかは扱っていない。予定表に列を足して管理する形になるが、金額の扱いは取引条件による。
手形の扱いが今後どうなるかも確認していない。紙の手形をやめる動きがあると聞いているが、条件を読み切れていない。電子記録債権の期日の計算は、手形と同じ式で出せるかどうか確かめていない。
支払日が土日祝のときに前営業日になるか翌営業日になるかは、取引の約定で決まる。上の式は前営業日で計算している。翌営業日にする取引先がいるなら、=WORKDAY(支払日-1,1,祝日!$A:$A)に替える。取引先ごとに列で持たせる形もある。
外貨建ての支払と、分割払いの扱いも入れていない。



