Công cụ Tạo Hóa Đơn Miễn Phí
Tạo một hóa đơn chuyên nghiệp, sau đó in nó hoặc lưu nó dưới dạng PDF · không cần đăng ký.
Thông tin của bạn
Lập hóa đơn cho
Chi tiết hóa đơn
Các dòng hóa đơn
| Mô tả | SL | Giá | Tổng |
|---|
Cách thức hoạt động
Nhập thông tin của doanh nghiệp của bạn, của khách hàng của bạn, thêm các dòng với số lượng và giá, và xác định một thuế suất nếu cần. Nhấp «In / Lưu dưới dạng PDF» để có một hóa đơn sạch sẽ và chuyên nghiệp. Sử dụng tùy chọn «Lưu dưới dạng PDF» trong hộp thoại in của trình duyệt để tải xuống. Tất cả diễn ra cục bộ · dữ liệu của bạn không bao giờ rời khỏi thiết bị của bạn.
Câu hỏi thường gặp
Tôi có thể lưu nó dưới dạng PDF không?
Có. Khi hộp thoại in mở ra, hãy chọn «Lưu dưới dạng PDF» (hoặc «Microsoft Print to PDF» trên Windows) làm đích thay vì một máy in vật lý.
Dữ liệu của tôi có được lưu trữ không?
Không. Tất cả dữ liệu hóa đơn vẫn ở trong trình duyệt của bạn và không bao giờ được truyền đi bất kỳ đâu. Bằng cách làm mới trang hoặc đóng tab, dữ liệu biến mất, trừ khi bạn đã in hoặc lưu chúng.
Tôi có thể tùy chỉnh vẻ ngoài không?
Bố cục in sử dụng một thiết kế chuyên nghiệp gọn gàng và phổ quát. Bạn có thể sửa đổi PDF được tạo trong bất kỳ trình chỉnh sửa PDF nào sau khi lưu để tùy chỉnh thêm.
Lịch sử ngắn của hóa đơn
Hóa đơn theo nghĩa rộng nhất của nó, một bản ghi viết về "X nợ Y vì Z", có tuổi xấp xỉ tuổi của chữ viết. Các tấm đất sét chữ hình nêm được khai quật tại Uruk (ở Iraq hiện đại) và có niên đại khoảng 3300 đến 3000 TCN bao gồm hàng nghìn ghi chép hành chính: danh sách khẩu phần lúa mạch, đếm gia súc, phân bổ bia, chuyển hàng giữa các kho đền thờ. Đây không phải là hóa đơn theo nghĩa pháp lý hiện đại, nhưng chúng là cùng một ý tưởng: một bản ghi của bên thứ ba bền lâu về một giao dịch thương mại. Nhiều tấm chữ hình nêm sớm nhất là hành chính chứ không phải văn học, chữ viết dường như được phát minh một phần để theo dõi ai nợ gì. Thương mại La Mã sau đó đã sử dụng các tấm gỗ phủ sáp (tabulae ceratae) cho các tài liệu kinh doanh ngắn hạn, các tấm Vindolanda từ một pháo đài La Mã trên Bức tường Hadrian (khoảng 90 đến 120 CN) bao gồm các mua hàng khẩu phần và danh sách nhà cung cấp.
Khoảnh khắc bước ngoặt cho hóa đơn hiện đại là việc xuất bản Summa de arithmetica, geometria, proportioni et proportionalità bởi tu sĩ dòng Phanxicô Luca Pacioli ở Venice vào năm 1494. Pacioli không phát minh ra ghi chép kép, các thương gia Venice và Genoa đã sử dụng nó ít nhất 150 năm trước ông, nhưng cuốn sách của ông là chuyên luận in đầu tiên giải thích nó một cách có hệ thống. Phần liên quan, "Particularis de computis et scripturis," thường được trích dẫn là tài liệu sáng lập của kế toán hiện đại. Đóng góp của Pacioli là hệ thống hóa ba cuốn sách mà mọi thương gia nên giữ: memoriale (memorandum), giornale (nhật ký), và quaderno (sổ cái). Hóa đơn như chúng ta biết nằm ở ranh giới giữa memoriale và giornale: tài liệu nguồn kích hoạt các mục trong sổ của cả người bán và người mua. Thông tin hóa đơn được Pacioli khuyến nghị, ngày tháng, các bên, các mục, giá cả, điều khoản thanh toán, hầu như không thay đổi trong 530 năm.
Đến thế kỷ 19, sổ hóa đơn giấy in sẵn với các bản sao carbon là hình thức kinh doanh thống trị. Trong suốt đầu đến giữa thế kỷ 20, giấy NCR ("no carbon required") phủ hóa chất đã thay thế các tờ carbon thực tế, và các máy in dot-matrix dạng tractor-feed tạo ra các bộ hóa đơn nhiều phần trực tiếp từ phần mềm kế toán. Đây là thế giới đã cho chúng ta layout hóa đơn 8.5×11" hoặc A4 mà PDF vẫn mô phỏng. Các tiêu chuẩn Electronic Data Interchange (EDI), UN/EDIFACT (từ 1987 trở đi, được UNECE quản lý) và ANSI X12 cũ hơn ở Bắc Mỹ, cho phép các đối tác thương mại lớn trao đổi hóa đơn có cấu trúc từ máy tính đến máy tính từ thập niên 1980. EDI hoạt động nhưng định dạng tin nhắn ngắn gọn, khó đọc đối với con người, và đắt để triển khai, vì vậy nó vẫn chủ yếu là hiện tượng Fortune 500. Những năm 2000 và 2010 đã đẩy hóa đơn có cấu trúc về phía các định dạng dựa trên XML, đặc biệt là UBL (Universal Business Language), một tiêu chuẩn OASIS lần đầu xuất bản dưới dạng UBL 1.0 vào năm 2004 và hiện ở UBL 2.4 (phát hành tháng 2 năm 2024).
Yêu cầu pháp lý hiện đại, một hóa đơn phải chứa những gì
Hoa Kỳ: không giống như phần lớn thế giới, Mỹ không có luật liên bang quy định những gì một hóa đơn phải chứa. Không có tương đương với Chỉ thị VAT của EU ở cấp liên bang. Những gì điều chỉnh việc lập hóa đơn là một loạt các quy tắc gián tiếp: luật thuế bán hàng của tiểu bang (mỗi trong 45 tiểu bang có thuế bán hàng áp đặt các yêu cầu lưu trữ riêng, thường là 4 năm); IRS Publication 583 (các doanh nghiệp phải giữ sách và hồ sơ "hiển thị thu nhập gộp, các khoản khấu trừ, và tín dụng của bạn", hóa đơn là tài liệu hỗ trợ chính); và quyết định Wayfair (South Dakota v. Wayfair, Inc., 138 S.Ct. 2080, được quyết định vào ngày 21 tháng 6 năm 2018), đã thay đổi ai phải thu thuế bán hàng qua biên giới tiểu bang và do đó thay đổi ai phải phát hành hóa đơn chi tiết thuế. Form 1099-NEC, được khôi phục vào năm 2020, có nghĩa là các doanh nghiệp trả cho nhà thầu 600 đô la hoặc nhiều hơn trong một năm cần phát hành 1099-NEC, với các hóa đơn của nhà thầu làm đường mòn giấy hỗ trợ.
Liên minh Châu Âu: xương sống pháp lý là Chỉ thị Hội đồng 2006/112/EC về hệ thống chung của thuế giá trị gia tăng ("Chỉ thị VAT"), được thông qua ngày 28 tháng 11 năm 2006. Các Điều 217 đến 240 điều chỉnh việc lập hóa đơn. Điều 226 liệt kê nội dung bắt buộc cho một hóa đơn VAT đầy đủ: ngày hóa đơn; số tuần tự xác định duy nhất hóa đơn; số nhận dạng VAT của nhà cung cấp; số nhận dạng VAT của khách hàng (cho B2B trong EU và reverse-charge); tên đầy đủ và địa chỉ của nhà cung cấp và khách hàng; mô tả hàng hóa hoặc dịch vụ; số lượng; ngày cung cấp (nếu khác với ngày hóa đơn); số tiền chịu thuế theo tỷ lệ VAT cộng với giá đơn vị không bao gồm VAT và bất kỳ chiết khấu nào; tỷ lệ VAT áp dụng; số tiền VAT phải trả; cho các giao dịch được miễn hoặc reverse-charge, một tham chiếu đến điều khoản liên quan của chỉ thị. Chỉ thị 2014/55/EU (16 tháng 4 năm 2014) đã làm cho việc lập hóa đơn điện tử có cấu trúc bắt buộc cho các giao dịch B2G trên toàn EU và yêu cầu xuất bản một tiêu chuẩn chung, đã trở thành EN 16931.
Làn sóng lập hóa đơn điện tử châu Âu (2019 đến 2028)
- Ý, lệnh SDI (có hiệu lực từ 1 tháng 1 năm 2019). Ý là quốc gia thành viên EU đầu tiên ra lệnh lập hóa đơn điện tử cho tất cả các giao dịch B2B và B2C, không chỉ B2G. Nền tảng được gọi là SdI, Sistema di Interscambio, do Agenzia delle Entrate điều hành. Mỗi hóa đơn giữa các bên đăng ký VAT Ý phải được truyền theo định dạng XML FatturaPA (một hồ sơ Ý của UBL/EN 16931) qua SdI. Từ ngày 1 tháng 7 năm 2022, lệnh đã được mở rộng cho hóa đơn đến/từ các đối tác nước ngoài.
- Pháp, Facturation Electronique (triển khai 2026 đến 2027). Ban đầu được lên lịch cho tháng 7 năm 2024, đã bị hoãn bởi Điều 91 của luật tài chính 2024 đến một lịch trình theo từng giai đoạn: 1 tháng 9 năm 2026, tất cả các doanh nghiệp Pháp phải có thể nhận hóa đơn điện tử có cấu trúc, các doanh nghiệp lớn và trung bình cũng phải phát hành chúng; 1 tháng 9 năm 2027, các doanh nghiệp nhỏ và siêu nhỏ phải phát hành. Mô hình Pháp sử dụng kiến trúc "Y": hóa đơn chảy qua cổng công cộng (PPF, do AIFE vận hành) hoặc qua "Plateformes de Dématérialisation Partenaires" tư nhân được công nhận.
- Đức, Wachstumschancengesetz (2025 đến 2028). Đạo luật Cơ hội Tăng trưởng của Đức, được thông qua bởi Bundestag vào ngày 17 tháng 11 năm 2023 và Bundesrat vào ngày 22 tháng 3 năm 2024, bao gồm lệnh lập hóa đơn điện tử. Việc triển khai theo từng giai đoạn theo §14 UStG: 1 tháng 1 năm 2025, mọi doanh nghiệp Đức hoạt động B2B phải có thể nhận hóa đơn điện tử có cấu trúc; 1 tháng 1 năm 2027, các doanh nghiệp có doanh thu năm trước trên 800.000 euro phải phát hành hóa đơn điện tử có cấu trúc; 1 tháng 1 năm 2028, nghĩa vụ mở rộng cho tất cả các doanh nghiệp B2B Đức còn lại bất kể quy mô. Các định dạng được chấp nhận: XRechnung (triển khai EN 16931 của Đức, bắt buộc cho B2G liên bang từ ngày 27 tháng 11 năm 2020) và ZUGFeRD 2.x.
Stack kỹ thuật hóa đơn có cấu trúc, EN 16931, PEPPOL, Factur-X / ZUGFeRD
EN 16931-1:2017 (với các sửa đổi tiếp theo) định nghĩa mô hình dữ liệu ngữ nghĩa, "số hóa đơn" hoặc "tham chiếu người mua" hoặc "loại thuế" có nghĩa là gì, độc lập với cú pháp được sử dụng để mã hóa chúng. EN 16931-2 liệt kê các binding cú pháp: UBL 2.1 (OASIS) và UN/CEFACT CII (Cross Industry Invoice). Tiêu chuẩn là tài liệu tham chiếu mà Ủy ban châu Âu yêu cầu theo Chỉ thị 2014/55/EU. PEPPOL (ban đầu là "Pan-European Public Procurement OnLine," hiện do OpenPeppol AISBL quản lý, thành lập năm 2012, có trụ sở tại Brussels) là một mạng lưới các điểm truy cập định tuyến các tài liệu kinh doanh có cấu trúc, phổ biến nhất là hóa đơn trong hồ sơ PEPPOL BIS Billing 3.0, mà bản thân nó là một ràng buộc của EN 16931 trong cú pháp UBL 2.1. PEPPOL bắt buộc cho B2G ở hơn 30 quốc gia (mọi thành viên EU/EEA, cộng với Singapore, đã áp dụng PEPPOL vào năm 2018 cho mạng InvoiceNow toàn quốc của mình, Úc, New Zealand, và Nhật Bản, đã áp dụng PEPPOL làm cơ sở cho Hệ thống Hóa đơn Đủ điều kiện theo cải cách hóa đơn thuế tiêu dùng có hiệu lực từ 1 tháng 10 năm 2023).
Đối với trường hợp doanh nghiệp nhỏ thực tế, gửi một hóa đơn mà con người có thể đọc và máy có thể phân tích, định dạng PDF hybrid là cầu nối. Factur-X (Pháp) và ZUGFeRD (Đức) về cơ bản là cùng một thứ, được cùng nhau điều chỉnh theo sự hợp tác năm 2017 giữa FNFE-MPE và FeRD. Về mặt kỹ thuật: một tệp PDF/A-3 (ISO 19005-3:2012) với một tệp đính kèm XML được nhúng phù hợp với EN 16931. PDF trực quan là cho con người; XML nhúng là cho phần mềm kế toán của người nhận. Vì PDF/A-3 là hồ sơ lưu trữ cho phép các tệp đính kèm tệp tùy ý, định dạng đáp ứng các yêu cầu bảo tồn lâu dài trong khi vẫn mang dữ liệu có thể đọc được bằng máy. Công cụ này tạo ra một PDF đơn giản, không phải Factur-X / ZUGFeRD / XRechnung. Đối với B2B của Đức hoặc Pháp từ ngày 2026/2027 trở đi, bạn sẽ muốn một nền tảng e-invoicing chuyên dụng có thể tạo định dạng có cấu trúc.
Một tổng hợp thực tế các trường yêu cầu
Lấy nền tảng chung từ thực tiễn ghi chép của Mỹ, Điều 226 của EU, hướng dẫn HMRC của Anh, và các lệnh e-invoice quốc gia khác nhau, một hóa đơn tuân thủ có thể bảo vệ được hầu như luôn bao gồm:
- Một số hóa đơn duy nhất (tuần tự, theo một sơ đồ đánh số có tài liệu, không bao giờ được sử dụng lại).
- Ngày phát hành, và nơi liên quan ngày cung cấp (thường được gọi là "tax point" trong các chế độ VAT).
- Nhà cung cấp: tên pháp lý, địa chỉ đã đăng ký, và số đăng ký thuế (VAT ID ở EU/UK, EIN ở Mỹ cho B2B).
- Khách hàng: tên và địa chỉ, cộng với tax ID của họ cho các giao dịch B2B trong EU và reverse-charge.
- Một mô tả rõ ràng của mỗi mục: bản chất của hàng hóa hoặc dịch vụ, số lượng, đơn giá.
- Tổng phụ (số tiền chịu thuế) theo tỷ lệ thuế.
- Tỷ lệ thuế và số tiền thuế, chi tiết hóa.
- Tổng số tiền phải trả theo đơn vị tiền tệ đã nêu.
- Điều khoản thanh toán, ngày đến hạn, phương thức được chấp nhận, và bất kỳ điều khoản thanh toán muộn nào.
- Đối với nguồn cung được miễn hoặc với mức thuế bằng không, cơ sở pháp lý (ví dụ: "Reverse charge, Điều 196 của Chỉ thị 2006/112/EC" cho các dịch vụ B2B xuyên biên giới trong EU).
Công cụ này hiển thị hầu hết các điều này ngoại trừ: trường tax-ID chuyên dụng, danh mục thuế trên mỗi dòng, và "ngày cung cấp" có cấu trúc tách biệt với ngày hóa đơn. Các khối địa chỉ chấp nhận tax ID dưới dạng văn bản tự do, có hiệu quả cho hầu hết các trường hợp freelance và doanh nghiệp nhỏ.
Thực hành tốt nhất đánh số hóa đơn
Ràng buộc pháp lý ở hầu hết các quyền tài phán VAT là "tuần tự và duy nhất". Thực hành tốt nhất đi xa hơn:
- Tuần tự với tiền tố năm:
2026-001,2026-002. Đặt lại mỗi tháng 1, làm rõ năm tài chính mà hóa đơn thuộc về. Được sử dụng bởi hầu hết các freelancer châu Âu. - Tiền tố khách hàng:
ACME-2026-04. Hữu ích nếu bạn lập hóa đơn cho rất ít khách hàng nhiều lần. - Dựa trên dự án/công việc:
PROJ123-INV-02. Phổ biến trong tư vấn và xây dựng. - Tuần tự thuần túy:
00001,00002. Đơn giản nhưng cho đối tác (hoặc đối thủ cạnh tranh) biết bạn lập hóa đơn bao nhiêu.
Qua tất cả các điều này quy tắc là: không bao giờ bỏ qua và không bao giờ sử dụng lại một số. Các hóa đơn đã xóa nên được ghi là vô hiệu thay vì số được tái chế. SDI Ý và các cơ quan tài chính Đức sẽ từ chối các nộp hồ sơ có khoảng trống không được tài liệu hóa.
Thị trường phần mềm lập hóa đơn freelance/SMB
Một chuyến tham quan ngắn:
- FreshBooks, được thành lập năm 2003 bởi Mike McDerment ở Toronto, bắt đầu là lập hóa đơn cloud cho các nhà tư vấn tự do.
- Wave Accounting, được thành lập năm 2010 ở Toronto, lập hóa đơn và kế toán miễn phí cho các doanh nghiệp nhỏ, kiếm tiền thông qua thanh toán và tính lương. Được mua bởi H&R Block vào ngày 11 tháng 6 năm 2019 với giá 405 triệu USD; tier lập hóa đơn miễn phí vẫn còn.
- Intuit QuickBooks Online, phát hành năm 2001, nền tảng kế toán doanh nghiệp nhỏ thống trị ở Mỹ. Lập hóa đơn là một trong nhiều mô-đun.
- Xero, được thành lập năm 2006 ở Wellington, New Zealand bởi Rod Drury. Kế toán cloud đã phát triển từ thị trường SMB antipodean thành một player toàn cầu.
- Zoho Invoice, một phần của Zoho Corporation (được thành lập năm 1996 bởi Sridhar Vembu). Sản phẩm Zoho Invoice độc lập miễn phí cho việc sử dụng không giới hạn.
- Invoice Ninja, nền tảng lập hóa đơn mã nguồn mở, được thành lập năm 2014 bởi Hillel Coren. Tự host (PHP/Laravel, giấy phép MIT) hoặc phiên bản cloud.
- Bill.com, được thành lập năm 2006 bởi René Lacerte, ban đầu là tự động hóa các khoản phải trả; sau đó đã thêm lập hóa đơn và tích hợp ngân hàng.
- Square Invoices, Block (trước đây là Square) đã thêm lập hóa đơn vào năm 2014; tích hợp với Square Payments và Cash App.
- Stripe Invoicing, Stripe đã ra mắt sản phẩm Invoicing độc lập của mình vào năm 2018, nhắm vào các nhà phát triển và doanh nghiệp trực tuyến đã sử dụng Stripe Billing.
- Mẫu Excel/Google Sheets, vẫn là cách mà một phần lớn của thế giới freelance tạo ra hóa đơn, đặc biệt cho một vài khách hàng đầu tiên trước khi bất kỳ SaaS nào được áp dụng.
Mẫu trên các đối thủ này: hầu hết yêu cầu một tài khoản, lưu trữ dữ liệu trong cloud, và kiếm tiền thông qua đăng ký, xử lý thanh toán, hoặc upsells. Định vị đối lập ưu tiên quyền riêng tư của công cụ này, không cần đăng ký, không có gì rời khỏi trình duyệt, thực sự khác biệt cho những người dùng không muốn mối quan hệ SaaS cho những gì, về cấu trúc, là một biểu mẫu một trang.
"In / Lưu PDF" thực sự hoạt động như thế nào ở đây
Công cụ này sử dụng pipeline in native của trình duyệt cộng với driver PDF của OS thay vì một thư viện PDF JavaScript. Khi bạn nhấp In / Lưu PDF, trình duyệt xây dựng một bản xem trước in từ HTML hóa đơn và mở hộp thoại in tiêu chuẩn. Từ đó, bạn chọn một điểm đến:
- Chrome / Edge: chọn "Lưu dưới dạng PDF" trong dropdown điểm đến.
- macOS (bất kỳ trình duyệt nào): nhấp vào dropdown "PDF" ở góc dưới bên trái của hộp thoại in để "Lưu dưới dạng PDF." macOS đã có Save as PDF trên toàn hệ thống kể từ Mac OS X 10.0 (2001).
- Windows: chọn "Microsoft Print to PDF" làm máy in. Điều này đã được thêm vào như một driver tích hợp trong Windows 10 (2015), trước đó bạn cần một máy in PDF bên thứ ba.
Chất lượng đầu ra xuất sắc: văn bản vector thực, font nhúng, nội dung có thể sao chép, cấu trúc có thể truy cập nếu HTML nguồn có thể truy cập. Sự đánh đổi mà công cụ đang thực hiện với cách tiếp cận này: bundle nhỏ hơn (không có jsPDF hoặc html2pdf được vận chuyển), không có gì rời khỏi thiết bị, chất lượng văn bản hoàn hảo, nhưng người dùng phải điều hướng hộp thoại in và chọn "Lưu dưới dạng PDF" tự mình. Đối với một công cụ miễn phí, không có tài khoản, đây là cuộc gọi đúng.
Các phương án thay thế mà các công cụ khác sử dụng: jsPDF (James Hall, 2012, MIT, ~100KB minified+gzipped, API lập trình để xây dựng PDF với văn bản và các nguyên thủy hình dạng), html2pdf.js (kết hợp html2canvas với jsPDF, dễ dàng hơn cho "làm cho trang của tôi trông giống như PDF" nhưng kết quả là một hình ảnh raster, không phải văn bản có thể tìm kiếm), pdfmake (API document-builder khai báo), và tạo ra phía máy chủ (wkhtmltopdf, Puppeteer/Chrome headless, weasyprint, những gì hầu hết các công cụ lập hóa đơn SaaS sử dụng, chất lượng cao nhất nhưng yêu cầu backend).
Thêm câu hỏi
Hóa đơn mà công cụ này tạo ra có tuân thủ pháp lý không?
Đối với lập hóa đơn Mỹ, trường hợp freelance/SMB của Điều 226 Chỉ thị VAT EU, và hầu hết các quyền tài phán khác mà PDF có thể đọc được bởi con người là đủ: có, miễn là bạn điền tất cả các trường yêu cầu (số hóa đơn tuần tự, ngày tháng, chi tiết nhà cung cấp và khách hàng với tax ID nếu được yêu cầu, hàng hóa/dịch vụ được chi tiết hóa với giá, phân tích thuế, tổng). Đối với Ý sau ngày 1 tháng 1 năm 2019, Pháp sau ngày 1 tháng 9 năm 2026/2027, Đức sau các ngày §14 UStG từ 2025 đến 2028, và bất kỳ giao dịch B2G nào trong EU, bạn sẽ cần một e-faktur có cấu trúc (XRechnung, FatturaPA, Factur-X / ZUGFeRD), mà công cụ này không tạo ra. Đối với những trường hợp đó, hãy sử dụng nền tảng e-invoicing chuyên dụng.
Tại sao chiết khấu được áp dụng trước thuế?
Công cụ này tuân theo quy ước phổ biến nhất: discount_amount = subtotal × (discount% / 100), sau đó tax_amount = (subtotal - discount_amount) × (tax% / 100). Điều này phù hợp với những gì Stripe Tax, Shopify, và hầu hết các gói kế toán làm. Nó không phổ quát, một số quyền tài phán (một số bang Mỹ có thuế "gross receipts" thay vì thuế bán hàng) đánh thuế số tiền trước chiết khấu. Nếu bạn ở trong một trong những trường hợp biên đó, bạn sẽ cần bỏ qua trường chiết khấu và tính tay dòng thuế.
Dữ liệu của tôi biến mất khi tôi làm mới. Nó ở đâu?
Đã biến mất, và đó là theo thiết kế. Công cụ này cố ý không duy trì bất kỳ dữ liệu nào: không có localStorage, không có IndexedDB, không có fetch đến server. Làm mới hoặc đóng tab xóa mọi thứ. Đảm bảo quyền riêng tư là không có gì về hóa đơn của bạn, người gửi, người nhận, số tiền, các mục dòng, tax ID, đã từng được lưu trữ ở bất kỳ đâu ngoài quy trình trình duyệt của bạn. Lưu PDF trước khi bạn đóng tab nếu bạn muốn một bản sao.
Tôi có thể thêm logo của mình không?
Không trực tiếp trong công cụ này. Khi bạn đã lưu PDF, bạn có thể thêm logo bằng cách sử dụng bất kỳ trình chỉnh sửa PDF nào (Adobe Acrobat, Foxit, Preview trên macOS, PDF Arranger miễn phí trên Linux). Hoặc bạn có thể mở hóa đơn đã in trong một công cụ như Word hoặc Google Docs bằng cách dán nội dung, thêm logo ở đó, và xuất lại. Quy trình logo-trên-hóa đơn là một yêu cầu nâng cấp phổ biến và là ứng cử viên cho phiên bản tương lai, hiện tại công cụ vẫn tập trung vào trường hợp cốt lõi không-đăng-ký, không-duy-trì-dữ-liệu.