無料請求書ジェネレーター
プロフェッショナルな請求書を作成し、印刷またはPDFとして保存 · 登録不要。
あなたの情報
請求先
請求書の詳細
請求書の明細
| 説明 | 数量 | 価格 | 合計 |
|---|
仕組み
ビジネス情報、クライアント情報を入力し、数量と価格付きの明細を追加し、必要に応じて税率を設定します。「印刷/PDFとして保存」をクリックして、クリーンでプロフェッショナルな請求書を取得します。ブラウザの印刷ダイアログで「PDFとして保存」オプションを使用してダウンロードします。すべてはローカルで行われます · データがデバイスを離れることはありません。
よくある質問
PDFとして保存できますか?
はい。印刷ダイアログが開いたら、物理プリンターの代わりに宛先として「PDFとして保存」(Windowsでは「Microsoft Print to PDF」)を選択します。
データは保存されますか?
いいえ。すべての請求書データはブラウザに残り、どこにも送信されません。ページを更新するかタブを閉じると、印刷または保存されていない限り、データは消えます。
外観をカスタマイズできますか?
印刷レイアウトはクリーンで普遍的なプロフェッショナルなデザインを使用しています。さらにカスタマイズするには、保存後にPDFエディタで生成されたPDFを変更できます。
請求書の簡単な歴史
最も緩い意味での請求書、「XがZのためにYに借りている」という書面記録は、文字そのものとほぼ同じ古さです。ウルク(現代のイラク)で発掘され、紀元前3300年から3000年頃に遡る楔形文字粘土板には、何千もの行政記録が含まれています: 大麦配給リスト、家畜の数、ビールの配分、寺院の貯蔵室間の物品の移動。これらは現代の法的意味での請求書ではありませんが、同じアイデアです: 商取引の永続的な第三者記録です。最初の楔形文字粘土板の多くは文学的というよりむしろ行政的なものであり、書字は部分的に誰が何を借りているかを追跡するために発明されたようです。後にローマ商業は短命の業務文書のために蝋でコーティングされた木製粘土板(tabulae ceratae)を使いました、ハドリアヌスの長城のローマの要塞からのヴィンドランダ粘土板(紀元90-120年頃)には配給購入と供給者リストが含まれています。
現代の請求書発行の分水嶺の瞬間は、フランシスコ会修道士ルカ・パチョーリによる1494年のヴェネツィアでのSumma de arithmetica, geometria, proportioni et proportionalitàの出版です。パチョーリは複式簿記を発明したわけではなく、ヴェネツィアとジェノヴァの商人は彼の少なくとも150年前からそれを使っていましたが、彼の本はそれを体系的に説明した最初の印刷された論文でした。関連するセクション「Particularis de computis et scripturis」は、現代会計の創設文書としてしばしば引用されます。パチョーリの貢献はすべての商人が保つべき3つの帳簿を成文化することでした: メモリアル(memorandum)、ジョルナーレ(journal)、クアデルノ(ledger)。私たちが知っている請求書はメモリアルとジョルナーレの境界にあります: 売り手と買い手の両方の帳簿に記入をトリガーするソース文書です。パチョーリが推奨した請求書情報、日付、当事者、項目、価格、支払条件は、530年でほとんど変わっていません。
19世紀までに、カーボンコピー付きのプリント済み紙の請求書帳が支配的なビジネスフォームでした。20世紀の初期から中期にかけて、NCR("no carbon required")化学コーティング紙が文字通りのカーボンシートを置き換え、トラクターフィードドットマトリックスプリンターが会計ソフトウェアから直接複数パートの請求書セットを生成しました。これがPDFがまだエミュレートしている8.5×11"またはA4の請求書レイアウトを私たちに与えた世界です。Electronic Data Interchange (EDI)規格、UN/EDIFACT(1987年以降、UNECEによって統治)と北米の古いANSI X12は、大規模な取引パートナーが1980年代からコンピューター対コンピューターで構造化された請求書を交換できるようにしました。EDIは機能しますが、メッセージ形式は簡潔で、人間が読みにくく、実装に高価で、主にFortune 500の現象に留まりました。2000年代と2010年代は構造化された請求書発行をXMLベースのフォーマット、特にUBL(Universal Business Language)、2004年にUBL 1.0として最初に公開され、現在UBL 2.4(2024年2月リリース)のOASIS規格、に向けて押し進めました。
現代の法的要件、請求書に含まれていなければならないもの
アメリカ合衆国: 世界のほとんどとは異なり、米国には請求書に含まれていなければならないものを義務付ける連邦法令がありません。連邦レベルでEU VAT指令に相当するものはありません。請求書発行を支配するのは、間接的なルールのスタックです: 州の売上税法(売上税のある45州のそれぞれが独自の保持要件を課し、通常4年); IRS Publication 583(企業は「総収入、控除、クレジットを示す」帳簿と記録を保持しなければならない、請求書が主要な裏付け文書); そしてWayfair決定(South Dakota v. Wayfair, Inc.、138 S.Ct. 2080、2018年6月21日に決定)、州境を越えて売上税を徴収しなければならない者を変え、ひいては税金詳細請求書を発行しなければならない者を変えました。2020年に再導入されたForm 1099-NECは、年間600ドル以上をコントラクターに支払う企業が1099-NECを発行し、コントラクターの請求書を裏付けペーパートレイルとして必要があることを意味します。
欧州連合: 法的バックボーンは付加価値税の共通システムに関する理事会指令 2006/112/EC(「VAT指令」)であり、2006年11月28日に採択されました。第217条から第240条が請求書発行を統治します。第226条は完全なVAT請求書のための必須内容をリストします: 請求書日付; 請求書を一意に識別する連続番号; 供給者のVAT識別番号; 顧客のVAT識別番号(B2B EU内およびリバースチャージのため); 供給者と顧客の完全な名前と住所; 商品またはサービスの説明; 数量; 供給日(請求書日付と異なる場合); VAT率ごとの課税額プラスVAT除外の単価と任意の割引; 適用されるVAT率; 支払うべきVAT額; 免除またはリバースチャージ取引については、指令の関連記事への参照。指令 2014/55/EU(2014年4月16日)はEU全体でB2G取引のために構造化されたe-請求書発行を義務化し、共通標準の公開を要求し、それがEN 16931となりました。
ヨーロッパのe-請求書発行の波(2019年から2028年)
- イタリア、SDI義務(2019年1月1日以来発効)。イタリアはB2GだけでなくすべてのB2BとB2C取引のための電子請求書発行を義務付けた最初のEU加盟国でした。プラットフォームはSdI、Sistema di Interscambioと呼ばれ、Agenzia delle Entrateによって運営されています。イタリアのVAT登録パーティ間のすべての請求書はSdIを通じてFatturaPA XML形式(UBL/EN 16931のイタリアプロファイル)で送信されなければなりません。2022年7月1日から、義務は外国カウンターパーティとの請求書に拡張されました。
- フランス、Facturation Electronique(2026年から2027年にロールアウト)。当初2024年7月に予定されていましたが、2024年財政法第91条によって段階的タイムラインに延期されました: 2026年9月1日、すべてのフランス企業は構造化された電子請求書を受信できる必要があり、大企業と中堅企業は発行も必要; 2027年9月1日、小規模および零細企業は発行しなければなりません。フランスモデルは「Y」アーキテクチャを使用します: 請求書は公的ポータル(PPF、AIFEによって運営)か認定された民間「Plateformes de Dématérialisation Partenaires」のいずれかを通じて流れます。
- ドイツ、Wachstumschancengesetz(2025年から2028年)。ドイツの成長機会法は、2023年11月17日にBundestagで、2024年3月22日にBundesratで可決され、e-請求書発行義務を含みます。§14 UStG下の段階的ロールアウト: 2025年1月1日、すべてのB2Bアクティブなドイツ企業は構造化されたe-請求書を受信できる必要があります; 2027年1月1日、前年売上高80万ユーロを超える企業は構造化されたe-請求書を発行しなければなりません; 2028年1月1日、義務はサイズに関係なく残りのすべてのB2Bドイツ企業に拡張されます。受け入れられた形式: XRechnung(ドイツEN 16931実装、2020年11月27日以来連邦B2Gで義務付け)とZUGFeRD 2.x。
構造化請求書の技術スタック、EN 16931、PEPPOL、Factur-X / ZUGFeRD
EN 16931-1:2017(その後の修正を含む)は、それらをエンコードするために使用される構文に関係なく、「請求書番号」または「買い手参照」または「税カテゴリ」が何を意味するかというセマンティックデータモデルを定義します。EN 16931-2は構文バインディングをリストします: UBL 2.1(OASIS)とUN/CEFACT CII(Cross Industry Invoice)。この標準は欧州委員会が指令2014/55/EU下で要求する参照文書です。PEPPOL(元々「Pan-European Public Procurement OnLine」、現在2012年に設立されブリュッセルに拠点を置くOpenPeppol AISBLによって統治)は、構造化されたビジネス文書、最も一般的にはPEPPOL BIS Billing 3.0プロファイルの請求書をルーティングするアクセスポイントのネットワークで、それ自体がUBL 2.1構文でのEN 16931の制約です。PEPPOLは30以上の国でB2Gに義務付けられています(すべてのEU/EEAメンバー、加えて2018年に全国InvoiceNowネットワークのためにPEPPOLを採用したシンガポール、オーストラリア、ニュージーランド、そして2023年10月1日に発効した消費税請求書改革下のQualified Invoice Systemの基礎としてPEPPOLを採用した日本)。
実用的な小規模企業のケースのために、人間が読めるそして機械がパースできる請求書を送るために、ハイブリッドPDF形式は橋です。Factur-X(フランス)とZUGFeRD(ドイツ)は本質的に同じもので、FNFE-MPEとFeRD間の2017年協力の下で共同で整列しています。技術的に: EN 16931に準拠する埋め込みXML添付ファイルを持つPDF/A-3ファイル(ISO 19005-3:2012)。視覚的なPDFは人間用です; 埋め込まれたXMLは受信者の会計ソフトウェア用です。PDF/A-3は任意のファイル添付を許可するアーカイブプロファイルなので、フォーマットは機械可読データを運ぶ間も長期保存要件を満たします。このツールは普通のPDFを生成します、Factur-X / ZUGFeRD / XRechnungではありません。2026/2027以降の日付からのドイツまたはフランスのB2Bには、構造化されたフォーマットを生成できる専用のe-請求書プラットフォームが必要です。
必須フィールドの実用的な統合
US記録保持実践、EU第226条、UK HMRCガイダンス、および様々な国のe-請求書義務から共通の基盤を引き出すと、防御可能に準拠した請求書はほとんど常に以下を含みます:
- 一意の請求書番号(連続的、文書化された番号付けスキームに従い、決して再使用しない)。
- 発行日、および関連する場所では供給日(VAT制度ではしばしば「tax point」と呼ばれる)。
- 供給者: 法的名称、登録住所、税務登録番号(EU/UKではVAT ID、B2BのUSではEIN)。
- 顧客: 名前と住所、加えてB2B EU内およびリバースチャージ取引のための税ID。
- 各項目の明確な説明: 商品またはサービスの性質、数量、単価。
- 税率ごとの小計(課税額)。
- 税率と税額、明細化。
- 支払うべき総額、指定された通貨で。
- 支払条件、期限、受け入れられる方法、および任意の遅延支払条件。
- 免除または ゼロ税率の供給については、法的根拠(例: EU内のクロスボーダーB2BサービスのためのDirective 2006/112/EC第196条のもとでの「Reverse charge」)。
このツールは以下を除いてこれらのほとんどを表面化します: 専用の税IDフィールド、行ごとの税カテゴリ、および請求書日付と別個の構造化された「供給日」。住所ブロックはフリーテキストとして税IDを受け入れます、これはほとんどのフリーランスおよび小規模企業のケースで機能します。
請求書番号付けのベストプラクティス
ほとんどのVAT管轄の法的制約は「連続的で一意」です。ベストプラクティスはさらに進みます:
- 年-プレフィックス連続:
2026-001,2026-002。毎年1月にリセット、請求書がどの会計年度に属するかを明らかにします。ほとんどのヨーロッパのフリーランサーが使用。 - 顧客-プレフィックス:
ACME-2026-04。非常に少ないクライアントに何度も請求する場合に有用。 - プロジェクト/ジョブベース:
PROJ123-INV-02。コンサルティングと建設で一般的。 - 純粋な連続:
00001,00002。シンプルですが、カウンターパーティ(または競合相手)にどれだけ請求しているかを伝えます。
これらすべてにわたるルールは: 絶対にスキップせず、絶対に番号を再使用しないこと。削除された請求書は番号がリサイクルされるのではなく、無効にされたものとして記録されるべきです。イタリアのSDIとドイツの財政当局は、文書化されていないギャップがあるシーケンスのファイリングを拒否します。
フリーランス/SMB請求書ソフトウェア市場
短いツアー:
- FreshBooks、2003年にMike McDermentによってトロントで設立、自営業コンサルタントのためのクラウド請求書発行として始まりました。
- Wave Accounting、2010年にトロントで設立、小規模企業のための無料の請求書発行と会計、支払いと給与で収益化。2019年6月11日にH&R Blockが4億500万米ドルで買収; 無料の請求書発行ティアは残ります。
- Intuit QuickBooks Online、2001年にリリース、支配的な米国小規模企業会計プラットフォーム。請求書発行は数十のモジュールのうちの1つです。
- Xero、2006年にニュージーランドのウェリントンでRod Druryによって設立。対蹠地のSMB市場からグローバルプレーヤーへと成長したクラウド会計。
- Zoho Invoice、Zoho Corporation(1996年にSridhar Vembuによって設立)の一部。スタンドアロンのZoho Invoice製品は無制限の使用のために無料です。
- Invoice Ninja、オープンソースの請求書発行プラットフォーム、2014年にHillel Corenによって設立。セルフホスト(PHP/Laravel、MITライセンス)またはクラウド版。
- Bill.com、2006年にRené Lacerteによって設立、もともと買掛金自動化; 後に請求書発行と銀行統合を追加。
- Square Invoices、Block(旧Square)は2014年に請求書発行を追加; Square PaymentsとCash Appと統合。
- Stripe Invoicing、Stripeは2018年にスタンドアロンのInvoicing製品を立ち上げ、Stripe Billingを既に使用しているデベロッパーとオンラインビジネスをターゲットにしています。
- Excel/Google Sheetsテンプレート、まだフリーランス世界の大部分が請求書を作成する方法、特にSaaSが採用される前の最初の数顧客のために。
これらの競合相手にわたるパターン: ほとんどがアカウントを必要とし、データをクラウドに保存し、サブスクリプション、支払い処理、またはアップセルを通じて収益化します。このツールのプライバシーファーストの対抗ポジショニング、サインアップなし、何もブラウザを離れないは、構造的に一ページのフォームであるもののためにSaaSの関係を望まないユーザーにとって本当に差別化されています。
ここで「印刷 / PDFとして保存」が実際にどう機能するか
このツールはJavaScript PDFライブラリではなくブラウザのネイティブ印刷パイプラインプラスOSのPDFドライバーを使用します。印刷 / PDFとして保存をクリックすると、ブラウザは請求書HTMLから印刷プレビューを構築し、標準の印刷ダイアログを開きます。そこから、宛先を選びます:
- Chrome / Edge: 宛先のドロップダウンで「PDFとして保存」を選択します。
- macOS(任意のブラウザ): 印刷ダイアログの左下にある「PDF」ドロップダウンをクリックして「PDFとして保存」。macOSはMac OS X 10.0(2001)以来システム全体でSave as PDFを持っています。
- Windows: プリンターとして「Microsoft Print to PDF」を選択します。これはWindows 10(2015)で組み込みドライバーとして追加されました、それ以前はサードパーティのPDFプリンターが必要でした。
出力品質は優れています: 本物のベクターテキスト、埋め込みフォント、コピー可能なコンテンツ、ソースHTMLがアクセシブルだった場合のアクセシブルな構造。このツールがこのアプローチで行っているトレードオフ: 小さなバンドル(jsPDFやhtml2pdfが出荷されない)、何もデバイスを離れない、完璧なテキスト品質、しかしユーザーは印刷ダイアログをナビゲートして「PDFとして保存」を自分で選ばなければなりません。無料、アカウントなしのツールのために、これは正しい呼び方です。
他のツールが使用する代替案: jsPDF(James Hall、2012、MIT、~100KB minified+gzipped、テキストとシェイププリミティブでPDFを構築するプログラマティックAPI)、html2pdf.js(html2canvasとjsPDFを組み合わせ、「ページをPDFのように見せる」のに簡単ですが、結果は検索可能なテキストではなくラスター画像)、pdfmake(宣言的document-builder API)、およびサーバーサイド生成(wkhtmltopdf、Puppeteer/Chromeヘッドレス、weasyprint、ほとんどのSaaS請求書発行ツールが使用するもの、最高品質ですがバックエンドが必要)。
さらなる質問
このツールが生成する請求書は法的に準拠していますか?
US請求書発行、EU VAT指令第226条フリーランス/SMBケース、および人間可読のPDFで十分なほとんどの他の管轄のために: はい、すべての必須フィールド(連続的な請求書番号、日付、必要なところで税IDを持つ供給者と顧客の詳細、価格付きの明細化された商品/サービス、税内訳、合計)を埋める限り。2019年1月1日後のイタリア、2026/2027年9月1日後のフランス、2025年から2028年の§14 UStG日付後のドイツ、およびEUのB2G取引については、構造化されたe-請求書(XRechnung、FatturaPA、Factur-X / ZUGFeRD)が必要で、このツールは生成しません。それらのケースには、専用のe-請求書プラットフォームを使用してください。
なぜ割引が税の前に適用されるのですか?
このツールは最も一般的な慣行に従います: discount_amount = subtotal × (discount% / 100)、その後tax_amount = (subtotal - discount_amount) × (tax% / 100)。これはStripe Tax、Shopify、およびほとんどの会計パッケージが行うことに一致します。普遍的ではありません、一部の管轄(売上税ではなく「gross receipts」税を持ついくつかの米国州)は割引前金額に課税します。それらのエッジケースの1つにいる場合、割引フィールドをスキップして税ラインを手計算する必要があります。
リフレッシュしたらデータが消えました。どこにありますか?
消えました、そしてそれは設計によるものです。このツールは意図的にデータを永続化しません: localStorageなし、IndexedDBなし、サーバーへのfetchなし。リフレッシュまたはタブを閉じるとすべてが消去されます。プライバシー保証は、あなたの請求書、送信者、受信者、金額、明細項目、税IDに関する何も、ブラウザプロセスの外のどこにも保存されたことがないということです。コピーが欲しい場合はタブを閉じる前にPDFを保存してください。
ロゴを追加できますか?
このツールでは直接できません。PDFを保存したら、任意のPDFエディター(Adobe Acrobat、Foxit、macOSのPreview、Linux上の無料PDF Arranger)を使ってロゴを追加できます。または、印刷された請求書をWordやGoogle Docsのようなツールで開き、コンテンツを貼り付け、そこにロゴを追加し、再エクスポートすることもできます。請求書にロゴワークフローは一般的なアップグレードリクエストで、将来のバージョンの候補です、今のところツールはサインアップなし、データ持続性なしのコアケースに焦点を当て続けています。