invoice PDF เหมือน e-invoice หรือไม่

ไม่ ordinary invoice PDF เป็น output ที่มนุษย์อ่านได้ ส่วน Factur-X หรือ ZUGFeRD e-invoice จะฝัง EN 16931 CII XML ใน PDF/A-3b wrapper ด้วย

invoice ที่ใช้ซ้ำควรใช้ endpoint ใด

ใช้ Template Render เมื่อ layout invoice เสถียรและ caller ควรส่งเฉพาะ template_id พร้อม data ใช้ JSON Render เมื่อโค้ดเป็นเจ้าของ layout

gPdf คำนวณภาษีให้หรือไม่

ไม่ billing หรือ accounting system ของคุณคำนวณภาษี totals discounts และ payment state ก่อนส่ง render data

invoice PDF ใช้ PDF/A ได้หรือไม่

ได้ JSON Render รองรับ PDF/A settings ใช้ E-Invoice Render โดยเฉพาะเมื่อ invoice ต้อง package เป็น Factur-X หรือ ZUGFeRD

ใบแจ้งหนี้และการเงิน

Invoice PDF API สำหรับระบบ billing และ finance

สร้าง ordinary invoice PDF จาก billing data ด้วย JSON Render หรือ Template Render โดยเก็บ tax และ accounting logic ไว้ในระบบของคุณ

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS billing backend / ERP / ระบบบัญชี / SaaS app

ลองใน Playground อ่านเอกสาร

งานที่ต้องทำให้เสร็จ

แปลงข้อมูล invoice จาก billing, ERP หรือ SaaS system ให้เป็น invoice PDF ที่อ่านได้ โดยเก็บ numbering, tax, payment state และ accounting semantics ไว้ในระบบของ caller

ควรใช้ API นี้เมื่อใด

คุณต้องการ ordinary invoice PDFs สำหรับลูกค้า receipts statements หรือ accounting exports
ระบบของคุณเป็นเจ้าของ invoice numbers, tax calculation, line items และ payment state อยู่แล้ว
คุณต้องการ tables, totals, metadata และ optional PDF/A settings โดยไม่ต้องรัน browser
คุณต้องการ contract แบบ template_id สำหรับ layout invoice ที่ใช้ซ้ำ

สิ่งที่ไม่ได้ทดแทน

คุณต้องการ legal e-invoice package เช่น Factur-X หรือ ZUGFeRD ให้ใช้ E-Invoice Render
คุณคาดหวังให้ gPdf คำนวณ tax, validate accounting rules หรือ reconcile payments
คุณต้องการแปลง arbitrary HTML invoice แทน structured JSON หรือ templates

ควรเรียก endpoint ใด

PRIMARY

/api/v1/pdf/render

JSON Render คือ path หลักสำหรับเวิร์กโฟลว์นี้.

SECONDARY 1

/api/v1/template-render

ใช้เมื่อเวิร์กโฟลว์ต้องการ API path ที่เกี่ยวข้อง สัญญาเทมเพลต หรือการค้นหา capability.

SECONDARY 2

/api/v1/e-invoice/render

Minimal request

POST /api/v1/pdf/render - header และ total ของ invoice ขั้นต่ำ

{
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 18, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "text",
          "x": 20,
          "y": 42,
          "content": "Bill to: Example Customer\nAmount due: USD 245.00",
          "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "line",
          "x1": 20,
          "y1": 62,
          "x2": 190,
          "y2": 62
        }
      ]
    }
  ]
}

gPdf จัดการอะไร

การเรนเดอร์ invoice PDF จาก JSON pages หรือ template data
text, tables, totals blocks, pagination, metadata และ optional PDF/A output
Template Render สำหรับ layout invoice ที่เสถียรและใช้โดยหลายระบบ
binary PDF response และ API error envelope ที่สม่ำเสมอ

ระบบของคุณรับผิดชอบอะไร

invoice numbers, payment state, tax calculation, discounts, credits และ ledger meaning
ข้อมูล customer และ issuer, line-item mapping, currencies และ rounding rules
retention, delivery, email, payment links และ reconciliation กับ accounting system

Production checklist

ยืนยันว่า field invoice ที่มองเห็นทุกตัว map เข้ากับ source billing data
ทดสอบ line-item overflow, ชื่อลูกค้าที่ยาว, invoice หลายหน้า และ totals
ตัดสินใจว่า layout ควรอยู่ใน JSON Render หรือ published template
แยก ordinary invoice PDF generation ออกจาก legal e-invoice packaging
จัดเก็บ request IDs และ output filenames คู่กับ invoice records ของคุณ

ขอบเขตของ claim

ordinary invoice PDFs ไม่เหมือน legal e-invoice mandates
gPdf เรนเดอร์เอกสาร invoice แต่ไม่คำนวณ tax หรือ accounting state
output Factur-X / ZUGFeRD อยู่ที่ POST /api/v1/e-invoice/render

ordinary invoices เทียบกับ e-invoices

ordinary invoice PDF คือเอกสารที่ลูกค้าของคุณอ่าน สามารถสร้างจาก JSON Render หรือ Template Render ได้ ระบบของคุณตัดสิน invoice number, taxes, line items, currency และ payment state จากนั้น gPdf เรนเดอร์ PDF ที่มองเห็นได้

legal e-invoice เป็นอีกเรื่องหนึ่ง Factur-X และ ZUGFeRD รวม invoice PDF/A-3b ที่อ่านได้กับ EN 16931 CII XML ที่ฝังอยู่ ใช้ POST /api/v1/e-invoice/render สำหรับแพ็กเกจนั้น

Template Render มักเป็น production endpoint

ทีม finance แทบไม่ต้องการให้ทุก service สร้างพิกัด invoice ใหม่เอง เส้นทางทั่วไปคือออกแบบ invoice ครั้งเดียว publish เป็นเทมเพลต แล้วให้ caller ใช้ template_id ที่เสถียรพร้อม data schema ส่วน JSON Render ยังมีประโยชน์สำหรับ custom layouts, internal tools และ template prototyping

เก็บ accounting logic ไว้ upstream

gPdf ควรได้รับ final display values ไม่ใช่ accounting decisions ที่ยังไม่สรุป คำนวณ tax, discounts, rounding, payment status และ invoice eligibility ก่อนเรียก render API วิธีนี้ทำให้ PDF output deterministic และรักษา financial system เป็น source of truth

FAQ

invoice PDF เหมือน e-invoice หรือไม่: ไม่ ordinary invoice PDF เป็น output ที่มนุษย์อ่านได้ ส่วน Factur-X หรือ ZUGFeRD e-invoice จะฝัง EN 16931 CII XML ใน PDF/A-3b wrapper ด้วย
invoice ที่ใช้ซ้ำควรใช้ endpoint ใด: ใช้ Template Render เมื่อ layout invoice เสถียรและ caller ควรส่งเฉพาะ template_id พร้อม data ใช้ JSON Render เมื่อโค้ดเป็นเจ้าของ layout
gPdf คำนวณภาษีให้หรือไม่: ไม่ billing หรือ accounting system ของคุณคำนวณภาษี totals discounts และ payment state ก่อนส่ง render data
invoice PDF ใช้ PDF/A ได้หรือไม่: ได้ JSON Render รองรับ PDF/A settings ใช้ E-Invoice Render โดยเฉพาะเมื่อ invoice ต้อง package เป็น Factur-X หรือ ZUGFeRD