伝票電子化の進め方｜手書き伝票と取引先の署名までを個別開発なしで一続きにした設計

1. 伝票電子化が進まない原因は「書く手間」ではなく、「伝票から伝票への書き写し」と「紙の回覧」にある
2. 伝票の種類ごとにデータを入れる表（トラン）を作り、伝票番号などを参照でつないで、ノーコードの業務アプリへ移す
3. ツールを選ぶのは最後にし、まずは手元の伝票を「項目」と「回る順番」に分解する

それぞれの具体的な理由は以下の通りです。

1. 本質：電子化が進まない原因は「書き写し」と「回覧」にある
手書きの伝票をパソコンで作れるようにしても、確認書に振替伝票の番号を書き写す作業や、紙を持って承認者の席を回る作業は残ります。伝票の電子化で減らすべきなのは、記入そのものよりも、この2つの作業です。

2. 実現方法：伝票ごとにトランを作り、伝票番号でつなぐ
今回の設計では、ノーコード・クラウドデータベース「Slopebase（スロープベース）」上に、伝票の種類ごとにデータを入れる表（トラン）を用意しました。確認書の「伝票番号」欄は、振替伝票のデータを参照する形にしています。こうしておくと、伝票番号を選んだ時点で伝発日が自動で入るため、書き写しが発生しません。取引先とのやり取りも、紙の郵送ではなく、PDFでの署名依頼と、署名済みPDFの登録で行います。

3. 着手順序：ツールを選ぶ前に、伝票を分解する
最初に手をつけるべきは、現在使っている伝票を1枚ずつ並べ、「どの欄を誰が書き、どの欄をどの伝票から写しているか」と「どの順番で誰の手を通るか」を書き出すことです。この整理が終われば、必要な機能は自然に絞り込まれます。具体的なシステムを選ぶのは、その後で十分です。

この進め方が向いている業務と、向いていない業務は次のとおりです。

向いている業務
社内の承認と取引先の署名が1つの書類に混ざっている業務、ある伝票の番号や日付を別の伝票へ書き写している業務、伝票の種類が複数あり明細の行数が伝票ごとに違う業務

向いていない業務
取引先が紙での受け渡ししか受け付けない業務、伝票が1種類だけでほかの伝票への書き写しがない業務

この記事で扱う範囲と、扱わない範囲

扱う範囲
販促費確認書・特価承認申請書・振替伝票という3種類の伝票を対象に、項目と回る順番への分解から、データ構造の設計、項目の型と桁数、あえてシステム化しなかった判断までを、要件定義・基本設計の内容から整理します。

扱わない範囲
次のテーマはそれぞれ独立した記事にまとめているため、本記事では深追いせず該当記事へご案内します。

どの帳票からペーパーレス化を始めるか

→ ペーパーレス化の事例と進め方

請求書の発行と送付の電子化

→ 請求書の電子化のやり方

押印の廃止と内部統制
→ 脱ハンコで内部統制を強化する実践ガイド

承認ルートの決め方

→承認ルート設計の実務ガイド

基幹システムとクラウドの連携方式

→ AS/400（現IBM i）サポート終了で考える2層ERPでの運用

マスタ管理の考え方

→ マスタデータ管理（MDM）とは？

1枚の確認書が社内と取引先の間を何度も往復する

販促費確認書は、小売店などの得意先から販売促進のための販促費を求められたときに、その費用をメーカーに負担してもらうための書類です。メーカーが負担する金額は、メーカーに支払う買掛金から差し引く（相殺する）形で精算します。

この確認書は、次の順番で社内と取引先の間を動いていました。

1. 得意先から販促費の要請がメールなどで届く
2. 担当者が要請の内容をもとにExcelで確認書を作り、紙に印刷する
3. 上長などが内容を簡単に確認し、担当者がメーカーへ送る
4. メーカーが署名・捺印して返送する
5. 内容に応じて振替伝票や販促企画書を発行し、その内容を確認書に書き加える
6. 確認書の最下部にある承認欄の5者（担当者・上長・仕入責任者・支店長・仕入業務部）が順に押印する
7. 基幹システムに販促費の内容を手入力する

確認書は、社内で作られてから取引先へ送られ、戻ってきたあとにもう一度社内を回ります。1枚の紙が「依頼書」「メーカーが承諾した証拠」「社内の稟議書」という3つの役割を同時に担っているため、どこか1か所で確認が滞ると、その後の手続きがすべて止まってしまいます。

振替伝票の番号と伝発日を、手で書き写し続ける構造

確認書の明細には、販促費の内容と金額に加えて、「伝発日」「伝票番号」「使用金額」「使用日付」という欄があります。伝発日と伝票番号は振替伝票を発行したときに、使用金額と使用日付は販売促進に使ったときに書き込む欄です。つまり確認書は、ほかの伝票ができあがるのを待って、あとから欄を書き足していく書類です。

振替伝票は手書きの複写式で、セールス・仕入課・仕入部・経理部・仕入先の5枚つづりになっています（経理部の控えは現在使っていません）。特価承認申請書も同じく手書きの複写式伝票で、商品ごとの仕入単価と、特価として承認された単価との差額を、明細に1行ずつ書いていきます。

実際に手間やミスが生まれやすいのは、同じ番号や金額を別の紙へ書き写すときと、最後に基幹システムへ打ち込み直すときです。原因は手書きであること自体ではなく、1つの取引の情報を人が書き写してつないでいる、業務の進め方にあります。

伝票の電子化は「誰が書き、誰が見て、誰に渡すか」で分ける

3種類の伝票を並べてみると、伝票ごとの特徴がはっきり分かれます。

販促費確認書
社外（メーカー）の署名が必要で、社内の承認者も多い伝票です。明細は3行で固定されています。

特価承認申請書
社外とのやり取りはありませんが、明細の行数が伝票ごとに変わります（設計では2〜6行を想定）。

振替伝票
社内の承認を経たあと、仕入先用の控えだけを社外へ渡す伝票です。

3種類をまとめて電子化しようとすると、求める機能が増えて検討が止まりがちです。伝票ごとに「社外の人が関わるか」「明細の行数は固定か、変わるか」「ほかの伝票へ情報を渡すか」の3点を確認すれば、伝票ごとにどのようなトランを用意すればよいかが見えてきます。

現物の伝票から差分表を作る手順とチェックリスト

伝票の電子化を進めるうえで一番の手がかりになるのは、実際に使っている伝票（現物）。今回も、Excelの確認書と、手書き伝票をスキャンした画像を並べて、記入欄を1つずつ書き出しました。手順は次のとおりです。

伝票を種類ごとに1枚ずつ用意し、すべての欄に番号を振る
欄ごとに「誰が書くか」「どの伝票から写しているか」「いつ書くか」を書き出す
ほかの伝票から写している欄に印をつけ、写し元の伝票と欄を書く
明細の行数が固定か、伝票ごとに変わるかを決める
承認欄・押印欄を並べ、誰がどの順番で確認しているかを確かめる
社外の人に見せる欄と、社内だけで使う欄を分ける

書き出した内容は、「欄の名前」「書く人」「書くタイミング」「写し元（伝票と欄）」「型（文字・数字・日付など）」「桁数」「見せる相手」の7列の表（差分表）にまとめれば十分です。

差分表を作るときのチェックリスト
□同じ情報（取引先名、伝票番号、金額など）が2つ以上の伝票に書かれていないか
□あとから書き足す欄（伝発日、使用金額など）がないか
□印刷済みの様式にだけ書かれている固定の文言（相殺に関する文言など）を見落としていないか
□承認欄の人数と順番が、伝票ごとに違っていないか
□複写の控えのうち、使われていない控えがないか

項目の桁数と値域を、伝票の現物から決めておく

項目の型（文字・数字・日付など）と桁数は、あとから変えると影響が大きいため、整理の段階で決めておきます。今回の設計では、たとえば次のように決めました。

1. 金額は整数で1〜9,999,999とし、円記号と3桁区切りを付けて表示する
2. 特価承認申請書の伝票番号は5で始まる6桁、振替伝票の伝票番号は8か9で始まる6桁で自動採番する
3. 商品コードは13桁のJANコードを2-5-6のハイフン区切りで表し、合計15桁で持つ

伝票番号は、先頭の数字を見れば伝票の種類が分かるように、現物で使われている番号のルールをそのまま引き継いでいます。

◆検討チェックリスト
□取引先と書類をやり取りする必要があるか（ある場合、取引先に新しい操作をお願いできるか）
□社内の承認は何段階あり、差し戻しは発生するか
□取引先・得意先・商品・勘定科目など、自社独自のマスタを管理する必要があるか
□ある伝票の番号や金額を、別の伝票で使っていないか
□基幹システムへ同じ内容を手入力していないか
□取引先に見せてよい情報と、社内だけに留める情報が分かれているか

◆システム選定のポイント
□取引先など社外の人を、ゲストとして招いて書類をやり取りできるか
□明細を親子構造（鑑と明細）で持ち、明細の合計を自動で計算できるか
□入力した内容から、伝票の様式どおりのPDFを出力できるか
□承認の段数や差し戻しを、自社の運用に合わせて設定できるか
□基幹システムへCSVなどでデータを渡せるか
□1業務から小さく始められ、利用者数に応じた無理のない課金体系か

マスタ5本とトラン5本で、3種類の電子伝票を持つ層構成

今回の設計では、マスタ（何度も使う基本情報の表）を5本、トラン（伝票1枚ごとのデータを入れる表）を5本用意しました。

マスタ
メーカー、支店、得意先、商品、勘定科目

トラン
販促費確認書（署名依頼）、特価承認申請書の鑑、特価承認申請書の明細、振替伝票、振替伝票（帳票出力用）

販促費確認書のトランは、紙の様式に合わせて、明細を3行分の項目として持たせています。1行あたり「販促費内容・金額・伝発日・伝票番号・使用金額・使用日付・備考・添付ファイル」の8項目があり、見出し部分と合わせて38項目です。

一方、特価承認申請書は明細の行数が伝票ごとに変わるため、鑑（見出し部分）と明細を分け、明細を鑑の下に何行でも追加できる「サブレコード」の形にしました。明細では「差額＝仕入単価−特価単価」「金額＝差額×数量」を計算式で求めます。鑑の合計欄には、明細の金額の合計（SUM）を自動で反映し、支店別の単価を使う場合は支店別の合計（SUMIFS）も自動で反映します。

商品を選ぶと、品名・規格・色・仕入単価が商品マスタから自動で入ります。担当者が手で入力するのは、数量と特価単価の2項目だけです。

表1 マスタ・トランの項目例（設計判断が読み取れる項目を抜粋）

出典：弊社が設計検討した要件定義・基本設計（マスタ設計）をもとに編集部作成

特価承認申請書の鑑と明細（差額と合計の自動計算）

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

伝票番号を参照にして、伝発日の書き写しをなくす

確認書の明細にある「伝票番号」欄は、当初は数字を直接入力する項目にしてほしいという要望でした。設計書の備考には、この欄の扱いを変えた理由が次のように残っています。

「整数項目がご希望であったが、伝発日の自動入力のため、本項目をトラン参照に」

伝票番号を振替伝票のデータへの参照にしておけば、番号を選んだ時点で、振替伝票の日付が伝発日として自動で入ります。番号と日付を別々に書き写す必要がなくなるため、取り違えが起きる作業そのものがなくなります。

同じように、特価承認申請書の明細にある「特価承認申請書No」は、選択式ではなく6桁の文字列にしています。備考には「セレクトにすると、登録時にサブレコードの関係で保存できない」とあります。鑑と明細を一度に保存する仕組みでは、選択式にすると保存できないため、文字列で持たせる形にしました。

販促費確認書の入力画面（伝票番号を参照にして伝発日を自動入力）

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

取引先には署名済みPDFを戻してもらい、社内の進捗は見せない

取引先とのやり取りは、確認書のデータから自動で作るPDFを使って行います。確認書のトランには、PDFに関する項目を4つ持たせています。

1. 帳票出力の結果として返ってくるPDF
2. そのPDFを確認書に写した「自動生成」のPDF（データフローという自動処理で写します）
3. メーカーが署名したあとにアップロードする「ご署名後」のPDF
4. 内容を直したときにPDFを作り直すための「帳票再生成」の選択項目

確認書を入力すると様式どおりのPDFができあがり、担当者が署名依頼を起票すると、メーカーの担当者にメールで通知が届きます。メーカー側はゲストとして画面に入り、PDFをダウンロードして署名し、署名済みのPDFを登録して社内の担当者を選びます。登録されると社内の担当者に通知が届き、社内の承認へ進みます。

このとき、社内の承認がどこまで進んでいるかは、メーカー側から見えないように設計しています。取引先に見せるのは、署名をお願いする書類と、その結果だけです。

社内の承認は、上長・支店長・仕入責任者・本社仕入業務部の順に、システム上の承認として残します。打ち合わせでは「印鑑などではなく、システム上の承認がわかればよい」という方針が確認されており、紙の承認欄に押していた印は、誰がいつ承認したかが記録に残る形に置き換えています。承認は5段階まで設定でき、差し戻しにも対応します。

署名依頼と署名済みPDFがそろった販促費確認書の画面

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

振替伝票の電子化で、仕入先の控えだけを紙に残した理由

振替伝票は、社内の承認を経たあと、仕入先用の控えに勘定科目を書き入れて渡す流れになっています。そこで、入力用の振替伝票のトランとは別に、帳票出力用のトランを用意しました。

帳票出力用のトランでは、仕入先控え用の「貸方科目」以外の項目を読み取り専用にしています。承認済みの内容はデータフローで自動的に写り、担当者が手を加えられるのは、仕入先に見せる科目の欄だけです。承認後に内容が書き換えられることを防ぎながら、仕入先に見せる科目の表記だけは調整できるようにしています。

このトランの伝票番号は、数値ではなく文字列で持たせています。備考には「文字列なのは、データフローのマッピングのため」とあります。トランからトランへデータを受け渡すときの目印（キー）として、形式をそろえるためです。伝票番号をキーにして必要な情報が1か所にそろうため、基幹システムへ渡すデータも、このトランから取り出せる構造になっています。

5枚つづりの紙については、社内用の控えの印刷をやめ、仕入先に渡す1枚だけを印刷する方針です。振替伝票を電子化するからといって、取引先が紙で受け取る運用まで一度に変える必要はありません。

振替伝票の帳票出力用の画面（仕入先控えの科目だけを入力）

出典：弊社のPoCで実装したSlopebaseの画面（一部の情報を伏せています）

業務フローの中であえてシステム化しなかった箇所

今回の設計では、次の処理を意図してシステムの外に残しています。

1. 得意先からの販促費の要請の受け付け 要請はメールなどで届くため、受け付けはこれまでどおりとし、確認書の入力から先をシステムで扱います
2. 特価承認申請書の、出力後の回覧 出力後の流れが複雑なため、今回はPDFの出力までを対象にしています
3. 振替伝票の仕入先控えの印刷 仕入先との受け渡しは紙のまま残しています
4. グループウェアとの連携 打ち合わせの中で、連携は対象外でよいと確認しています

すべてを一度に電子化するのではなく、書き写しや紙の回覧が多い部分から電子化する、という考え方で範囲を決めています。

検討して外した選択肢と却下理由

今回の検討では、社内ですでに使っていたグループウェアのワークフロー機能で伝票を回すことも考えました。しかし、機能が足りないと判断して見送っています。

費用と期間の面では、使い慣れたグループウェアのほうが有利です。それでも見送ったのは、機能の範囲が足りなかったためです。要件一覧には、「取引先との書類の送付と受領」「鑑と明細を持つ伝票と、合計の自動計算」「入力内容からの帳票のPDF出力」「マスタの参照」「基幹システムへのデータ連携」が並んでおり、これらを1つの仕組みでまかなえることが選定の前提になりました。

既製品で足りるケース

一方で、業務に合わせて作る必要がないケースもあります。

1. 電子化したい伝票が経理の仕訳伝票だけで、取引先が関わらない場合は、会計ソフトの伝票入力機能で足ります
2. 紙の伝票をそのまま画像として保存したいだけなら、OCRやスキャンのサービスで足ります
3. 承認の手続きだけを電子化したい場合は、ワークフロー専用のツールで足ります

電子化の方法ごとの違いは、ペーパーレス化の事例と進め方で整理しています。

社内で挙がった懸念への回答

検討の過程では、「基幹システムへデータを連携できなければ、基幹システムへの手入力が残るので意味がない」という意見が挙がりました。もっともな懸念で、要件一覧にも基幹システムへのデータ連携を要件として明記しています。

設計の上では、伝票番号をキーにして、承認済みの内容が帳票出力用のトランにそろう構造にしてあります。取り込み方式（CSVなどの形式や項目）は情報システム担当と決める必要がありますが、渡すデータの置き場所が決まっているため、検討する範囲を1か所に絞り込めます。基幹システムとクラウドの役割分担については、AS/400（現IBM i）サポート終了で考える2層ERPでの運用で詳しく解説しています。

検討が始まる前の状況は、次のようなものでした。

「基幹システムを中心にした業務なので、紙の帳票と紙の伝票を回覧して、紙の伝票の内容を基幹システムへパンチ入力するのが当たり前でした」

負担に感じていたのは、伝票の印刷、回覧、そしてパンチ入力の3つです。展示会で製品を知ったことをきっかけに検討が始まりましたが、最初から前向きだったわけではありません。

「やりたいことが1つの製品で本当にできるのか、という疑問がありました。やりたいことが増えるたびに費用が高くなって、途中で頓挫するのではないかとも思っていました」

検討の場では、この疑問を踏まえて、「紙から電子への切り替えが社内に浸透しそうか」「いまの伝票業務を本当に電子で回せるか」の2点を確かめたい点として挙げました。

Q.伝票を電子化したら、紙の原本は保存しなくてよいですか？

A.保存の扱いは、書類の種類と受け渡しの方法によって変わります。取引先とPDFなどの電子データでやり取りした書類は「電子取引」にあたり、電子帳簿保存法にもとづいて電子データのまま保存する必要があります。紙で受け取った書類をスキャンして保存する場合は、別の要件が定められています。詳しくは国税庁の電子帳簿保存法関係のページをご確認のうえ、個別の判断は所轄税務署または専門家にご相談ください。

Q.手書き伝票の電子化は、OCRで読み取る方法と何が違いますか？

A.OCRは、手書きされた伝票を読み取ってデータにする方法で、紙に書く作業は残ります。今回の設計は、書く段階から画面に入力し、商品や取引先はマスタから選ぶ方法です。書き写しや合計の計算をシステムに任せられるため、ほかの伝票へ番号や金額を書き写している業務ほど、効果の違いが大きくなります。

Q.取引先が紙でのやり取りを希望したらどうすればよいですか？

A.すべてを一度に電子へ切り替える必要はありません。今回の設計でも、振替伝票の仕入先控えは紙で渡す運用を残しています。署名が必要な書類でも、取引先にお願いするのはPDFのダウンロードと署名済みPDFの登録だけです。お願いする操作を最小限にすることが、受け入れてもらうための近道です。

Q.振替伝票を電子化しても、基幹システムへの手入力は残りませんか？

A.電子化の範囲を伝票の作成と承認までに留めると、基幹システムへの入力は残ります。手入力をなくすには、承認済みのデータを基幹システムが取り込める形で渡す必要があります。今回の設計では、伝票番号をキーにして承認済みの内容を1か所にそろえ、基幹システムへ渡すデータを取り出せる構造にしています。取り込み方式は、基幹システム側の担当者と早めに相談しておくことをおすすめします。