Skip to main content

​
Account Payable Entry Form

​
Structure of an AP Entry Form

A good form is typically divided into three sections:
  1. Header Information: Details about the vendor and the invoice document itself.
  2. Line Item / Distribution: Details on what was purchased and how it should be coded in your accounting system (this part drives the journal entry).
  3. Summary & Approval: Totals that must match the invoice and internal control/workflow information.

​
Section 1: Header Information (Who and What)

This section identifies the vendor and the specific invoice being processed.
  • Vendor Name: The name of the company you need to pay.
  • (Best Practice: Use a dropdown list that pulls from your master vendor list to prevent duplicates and typos. Include a Vendor ID/Code if you use one.)
  • Invoice Number: The unique number the vendor assigned to their invoice.
  • (This is CRITICAL to prevent paying the same invoice twice.)
  • Invoice Date: The date the vendor created the invoice. This is used for aging reports.
  • Date Received: The date your company received the invoice. Useful for tracking internal processing time.
  • Invoice Due Date: The date the payment is due.
  • Payment Terms: The terms agreed upon with the vendor (e.g., Net 30, 2/10 Net 30). The system can often calculate the due date from the invoice date and terms.
  • Purchase Order (PO) Number: If the purchase was pre-authorized with a PO, this number links the invoice to the original order. This is key for 3-way matching (matching the PO, receiving report, and invoice).
  • Memo / Description: A brief, overall description of the invoice (e.g., “Monthly Office Cleaning - October 2023”).

​
Section 2: Line Items / GL Distribution (The “Why”)

This is the most important section for accounting. It details what the money was spent on and dictates the debit side of your journal entry. An invoice can be split across multiple accounts, departments, or projects.
  • Description: A detailed description of the product or service for a specific line item (e.g., “Paper, toner, pens”).
  • GL Account Number: The General Ledger account to be debited. This is the expense account (e.g., 6510 - Office Supplies, 7200 - Professional Fees, 1510 - Fixed Assets).
  • (Best Practice: Use a searchable dropdown list of your Chart of Accounts.)
  • Amount: The amount for that specific line item.
  • Department / Cost Center: (Optional but common) For internal budgeting and reporting, this specifies which department’s budget the expense belongs to.
  • Job / Project Code: (Optional) If the expense is for a specific customer job or internal project.
  • Quantity / Unit Price: (Optional) Sometimes useful to break down the cost further, but often just the total Amount per line is sufficient.
(Your form should allow for multiple line items. For example, one invoice from a consultant could have one line for “Consulting Fees” and another for “Reimbursed Travel Expenses,” hitting two different GL accounts.)

​
Section 3: Summary & Approvals (Control and Workflow)

This section ensures the numbers match the physical invoice and tracks internal workflow.
  • Subtotal: The total of all line items before taxes and other charges.
  • Sales Tax: The amount of tax charged by the vendor.
  • Shipping / Freight: Any shipping costs.
  • Invoice Total: The grand total of the invoice.
  • (CRITICAL CONTROL: The sum of all line item amounts + tax + shipping MUST equal the Invoice Total. Your form or system should validate this.)
  • Attachment: A field to upload a digital copy (PDF/scan) of the original vendor invoice. This is essential for a paperless audit trail.
  • Entered By: The user ID or name of the person performing the data entry.
  • Date Entered: The date the entry was made.
  • Approved By: The manager or authorized person who approved the invoice for payment.
  • Date Approved: The date of approval.

​
The Flow in Action: From Form to Journal Entry

Let’s see how the form fields translate into a journal entry. Scenario: You receive an invoice for 525from"Staples"forofficesupplies.525 from "Staples" for office supplies. 500 is for supplies and $25 is for sales tax. 1. Invoice from Vendor:
  • Vendor: Staples
  • Invoice #: INV-9876
  • Total: $525
2. AP Entry Form Filled Out:
  • Header:
  • Vendor Name: Staples
  • Invoice Number: INV-9876
  • Invoice Date: 10/26/2023
  • Due Date: 11/25/2023
  • Invoice Total: 525.00
  • Line Items:
  • Line 1:
  • Description: “Office Supplies for Q4”
  • GL Account: 6510 - Office Supplies Expense
  • Amount: 500.00
  • Line 2:
  • Description: “Sales Tax”
  • GL Account: 6515 - Sales Tax Expense (or it could be coded to the same account)
  • Amount: 25.00
3. Journal Entry Generated: When you save the AP entry, the accounting system automatically creates the following journal entry. The form fields directly determine the accounts and amounts.
Account NumberAccount NameDebitCredit
6510Office Supplies Expense$500.00
6515Sales Tax Expense$25.00
2000Accounts Payable$525.00
To record invoice INV-9876 from Staples
  • The Debits come from the GL Account and Amount fields in the Line Items section.
  • The Credit is always to the Accounts Payable liability account for the Invoice Total.
This entry correctly increases your expenses (debit) and increases your liability to the vendor (credit). When you later pay the bill, another journal entry will be made to Debit Accounts Payable and Credit Cash.

​
Sample Form Layout (Simplified)

=====================================================
            ACCOUNTS PAYABLE INVOICE ENTRY
=====================================================

--- HEADER INFORMATION ---
Vendor Name: [Dropdown List of Vendors]  Vendor ID: [Auto-populates]
Invoice #:   [Text Box] *Required
Invoice Date:[Date Picker] *Required    Date Received: [Date Picker]
Due Date:    [Date Picker] *Required    Payment Terms: [Dropdown: Net 30, etc.]
PO Number:   [Text Box]

--- LINE ITEM DISTRIBUTION (Add more lines as needed) ---
# | GL Account                 | Description                       | Amount      | Dept
--|----------------------------|-----------------------------------|-------------|---------
1 | [Dropdown/Search] *Req     | [Text Box]                        | [Number] *Req | [Dropdown]
2 | [Dropdown/Search]          | [Text Box]                        | [Number]    | [Dropdown]
3 | [Dropdown/Search]          | [Text Box]                        | [Number]    | [Dropdown]

--- TOTALS & ATTACHMENT ---
Subtotal:    [Auto-calculated]
Sales Tax:   [Number]
Shipping:    [Number]
-------------------------------
Invoice Total: [Number] *Required (Must match vendor invoice)

[ Attach Invoice File (PDF, JPG) ]

--- WORKFLOW ---
Entered By:  [Auto-user]             Date: [Auto-date]
Approved By: [Dropdown of Approvers]   Status: [Pending Approval]

​
Transform Invoice to AP

This is a very common and efficient workflow in modern accounting systems. You are essentially separating the initial data capture of the invoice from the accounting classification (the AP entry). Let’s break this down into two parts:
  1. The Database Fields: Defining the fields for your Invoices table.
  2. The Field-to-Field Relation: Mapping the fields from the Invoices table to your AP Entry Form.

​
Part 1: Common Fields for an Invoices Table

This table acts as a digital representation of the physical or PDF invoices you receive. Its primary job is to capture all the data exactly as it appears on the vendor’s document. Table: Invoices (Header Information)
Field NameData TypeDescriptionExample
invoice_idInteger (PK)Unique internal ID for the database record.1024
vendor_idInteger (FK)Foreign key linking to your Vendors master table.58 (for “Staples”)
vendor_invoice_numberVarcharThe key field. The unique number from the vendor’s invoice.INV-9876
invoice_dateDateThe date printed on the invoice.2023-10-26
date_receivedDateThe date your company received the invoice.2023-10-28
due_dateDateThe payment due date from the invoice.2023-11-25
po_numberVarchar (Nullable)The Purchase Order number referenced on the invoice, if any.PO-2023-152
invoice_subtotalDecimalThe total amount before taxes and shipping.500.00
tax_amountDecimalTotal sales tax amount.25.00
shipping_amountDecimalTotal shipping/freight charges.0.00
invoice_totalDecimalThe final, total amount of the invoice.525.00
invoice_statusVarcharTracks the invoice’s lifecycle (Received, Pending_AP, Processed).Pending_AP
attachment_pathVarcharFile path or URL to the scanned invoice image/PDF./docs/inv-9876.pdf
Table: Invoice_Line_Items (Details) An invoice has a one-to-many relationship with its line items.
Field NameData TypeDescriptionExample
line_idInteger (PK)Unique internal ID for the line item.3051
invoice_idInteger (FK)Links this line back to the Invoices table.1024
line_numberIntegerThe order of the item on the invoice (1, 2, 3…).1
item_descriptionTextThe description from the invoice line.”Case of 8.5x11 Printer Paper”
quantityDecimalThe quantity of the item purchased.10
unit_priceDecimalThe price per unit.50.00
line_totalDecimalThe total for this line (quantity * unit_price).500.00

​
Part 2: Field-to-Field Relation (Invoice Table -> AP Entry Form)

This is the core of your request. When a user selects an invoice_number (INV-9876 in our example), your application fetches the data from the tables above and uses the following mapping to populate the AP Entry Form.
AP Entry Form FieldSource Invoices Table FieldSource Invoice_Line_Items Table FieldLogic & Notes
--- HEADER ---
Vendor Namevendor_id (via lookup)The vendor_id is used to look up the full vendor name from the Vendors table. This field is usually read-only.
Invoice Numbervendor_invoice_numberThis is the key field used to initiate the data load. It is read-only after selection.
Invoice Dateinvoice_dateDirect 1-to-1 mapping. Populated and made read-only.
Due Datedue_dateDirect 1-to-1 mapping. Populated and made read-only.
PO Numberpo_numberDirect 1-to-1 mapping. Populated and made read-only.
Invoice Total (for validation)invoice_totalThis is the most critical control field. It’s loaded into a read-only field on the form. The sum of the distribution lines below must equal this amount before the entry can be saved.
Attachment Linkattachment_pathThe form should display a clickable link to the stored invoice document so the user can view it while coding the expenses.
--- LINE ITEMS / DISTRIBUTION ---This is where the user does their work. The system can pre-populate these lines based on the Invoice_Line_Items, but the user must provide the GL codes.
Description (of the expense)item_descriptionThe item_description from each line item on the invoice is used to pre-populate the description on each distribution line of the AP form. The user can edit or append to this.
Amount (of the expense)line_totalThe line_total from the invoice line item populates the Amount for the corresponding AP distribution line. This might be editable if the user needs to split a single line across multiple GL accounts.
GL AccountN/AN/AThis is new data added by the user. This is the core purpose of the AP Entry Form. The user selects the appropriate expense account from the Chart of Accounts.
Department / Cost CenterN/AN/AThis is new data added by the user. The user assigns the cost to the correct internal department.
Project CodeN/AN/AThis is new data added by the user.
--- SUMMARY & WORKFLOW ---
Subtotalinvoice_subtotalCan be displayed for reference.
Sales Taxtax_amountOften, tax is entered as a separate distribution line. The system can suggest a line item for tax with the tax_amount pre-filled, and the user just needs to select the Sales Tax Expense GL account.
Shippingshipping_amountSimilar to tax, this can be pre-populated on a separate distribution line, requiring only a GL account from the user.

​
The AJAX-driven Flow in Action:

  1. User Action: Clicks “Create AP Entry”.
  2. System Action: User is prompted to select an unprocessed invoice (e.g., from a dropdown where Invoices.invoice_status = 'Pending_AP'). User selects INV-9876.
  3. AJAX Call: The front-end sends vendor_invoice_number: 'INV-9876' to the back-end.
  4. Back-End Logic:
  • Find the record in the Invoices table where vendor_invoice_number matches.
  • Find all associated records in the Invoice_Line_Items table using the invoice_id.
  • Fetch the vendor_name from the Vendors table.
  • Bundle all this data into a JSON object.
  1. Front-End Population:
  • The AJAX call returns the JSON object.
  • Your JavaScript uses the mapping table above to populate the AP form fields:
  • form.vendorName.value = json.vendor_name
  • form.invoiceNumber.value = json.vendor_invoice_number
  • form.invoiceTotal.value = json.invoice_total
  • It then iterates through json.line_items to create the initial distribution lines, filling in Description and Amount for each. The GL Account field is left blank for the user to complete.
This structure cleanly separates raw data from accounting interpretation, provides a strong audit trail by linking the AP entry directly to the source invoice, and dramatically speeds up data entry by pre-populating known information.

​
Bahasa Indonesia

Berikut adalah dokumentasi lengkap yang menggabungkan semua penjelasan sebelumnya—alur kerja, struktur data, dan pemetaan kolom—dan diterjemahkan ke dalam Bahasa Indonesia.

​
Dokumentasi Alur dan Struktur Data untuk Entri Hutang Usaha (Accounts Payable)

Dokumen ini menjelaskan alur kerja, struktur data, dan relasi kolom yang direkomendasikan untuk membuat formulir entri Hutang Usaha (Accounts Payable/AP). Tujuannya adalah untuk menciptakan alur kerja yang efisien di mana data dari invoice vendor pertama kali dicatat, kemudian digunakan untuk mengisi formulir entri AP secara otomatis, yang pada akhirnya akan menghasilkan Jurnal Akuntansi yang akurat.

​
Bagian 1: Alur Kerja Keseluruhan (Overall Workflow)

Alur kerja yang diusulkan memisahkan proses pencatatan data invoice dari proses klasifikasi akuntansi untuk meningkatkan kecepatan dan akurasi.
  1. Pencatatan Invoice: Data dari invoice fisik atau PDF yang diterima dari vendor dicatat terlebih dahulu ke dalam sistem (Tabel Invoices). Tahap ini hanya fokus pada pencatatan data apa adanya dari dokumen sumber. Status invoice diatur menjadi Pending AP Entry.
  2. Pembuatan Entri AP: Staf Akuntansi memulai proses dengan membuat “Entri AP Baru”.
  3. Pemilihan Sumber Data: Pengguna memilih nomor invoice dari daftar invoice yang statusnya masih Pending AP Entry.
  4. Pengisian Formulir Otomatis: Setelah nomor invoice dipilih, sistem secara otomatis (via AJAX) mengambil data dari tabel Invoices dan mengisi kolom-kolom yang relevan di formulir Entri AP (seperti nama vendor, tanggal, total, dll.).
  5. Distribusi Akuntansi: Pengguna melengkapi formulir dengan menambahkan informasi akuntansi, yaitu memilih Akun GL (General Ledger) dan alokasi departemen/proyek untuk setiap baris pengeluaran.
  6. Pembuatan Jurnal: Setelah formulir disimpan, sistem secara otomatis membuat Jurnal Akuntansi yang sesuai: Debit ke akun Beban dan Kredit ke akun Hutang Usaha (Accounts Payable).

​
Bagian 2: Struktur Tabel Database (Database Table Structure)

Untuk mendukung alur kerja ini, dibutuhkan setidaknya dua tabel utama.

​
Tabel 1: Invoices (Data Header Invoice)

Tabel ini menyimpan informasi utama dari setiap invoice yang diterima.
Nama Kolom (Field Name)Tipe Data (Data Type)DeskripsiContoh
invoice_idInteger (PK)ID unik internal untuk setiap record invoice di database.1024
vendor_idInteger (FK)Foreign Key yang terhubung ke tabel master Vendors.58 (untuk “CV Jaya Abadi”)
vendor_invoice_numberVarcharKolom Kunci. Nomor unik yang tertera pada invoice vendor.INV-9876
invoice_dateDateTanggal yang tercetak di invoice.2023-10-26
date_receivedDateTanggal saat perusahaan menerima invoice.2023-10-28
due_dateDateTanggal jatuh tempo pembayaran.2023-11-25
invoice_subtotalDecimalTotal jumlah sebelum pajak dan biaya lainnya.5000000
tax_amountDecimalJumlah PPN atau pajak lainnya.550000
shipping_amountDecimalBiaya pengiriman.50000
invoice_totalDecimalJumlah total akhir dari invoice.5600000
invoice_statusVarcharStatus siklus invoice (Received, Pending_AP, Processed).Pending_AP
attachment_pathVarcharLokasi file atau URL dari hasil scan invoice (PDF/gambar)./docs/inv-9876.pdf

​
Tabel 2: Invoice_Line_Items (Data Rincian Invoice)

Tabel ini menyimpan rincian barang atau jasa dari sebuah invoice.
Nama Kolom (Field Name)Tipe Data (Data Type)DeskripsiContoh
line_idInteger (PK)ID unik internal untuk setiap baris rincian.3051
invoice_idInteger (FK)Foreign Key yang terhubung ke tabel Invoices.1024
item_descriptionTextDeskripsi barang atau jasa dari baris invoice.”Jasa Konsultasi Pemasaran Oktober”
quantityDecimalKuantitas barang atau jasa.1
unit_priceDecimalHarga per unit.5000000
line_totalDecimalTotal untuk baris ini (quantity * unit_price).5000000

​
Bagian 3: Relasi Kolom: Tabel Invoice ke Formulir Entri AP

Ini adalah pemetaan kunci yang menjelaskan bagaimana data dari database secara otomatis mengisi formulir Entri AP saat pengguna memilih sebuah nomor invoice.
Kolom di Formulir Entri APSumber dari Tabel InvoicesSumber dari Tabel Invoice_Line_ItemsLogika & Catatan
--- BAGIAN HEADER ---
Nama Vendorvendor_id (via lookup)ID vendor digunakan untuk mencari nama lengkap vendor dari tabel master. Kolom ini tidak bisa diubah (read-only).
Nomor Invoicevendor_invoice_numberKolom ini menjadi kunci untuk memuat data. Kolom ini tidak bisa diubah setelah dipilih.
Tanggal Invoiceinvoice_dateDipetakan langsung 1-ke-1. Kolom ini tidak bisa diubah.
Tanggal Jatuh Tempodue_dateDipetakan langsung 1-ke-1. Kolom ini tidak bisa diubah.
Total Invoice (untuk validasi)invoice_totalNilai ini dimuat ke kolom read-only sebagai kontrol. Total dari baris distribusi di bawah harus sama dengan nilai ini agar formulir bisa disimpan.
Link Lampiranattachment_pathMenampilkan link ke dokumen invoice agar pengguna bisa melihatnya saat melakukan pengkodean.
--- BAGIAN DISTRIBUSI / RINCIAN AKUNTANSI ---Di sinilah pengguna melakukan input utama. Sistem mengisi Deskripsi dan Jumlah, tetapi pengguna harus mengisi Akun GL.
Deskripsi (Beban)item_descriptionDeskripsi dari setiap baris invoice digunakan untuk mengisi deskripsi di baris distribusi AP. Pengguna bisa mengeditnya.
Jumlah (Beban)line_totalJumlah dari setiap baris invoice mengisi kolom Jumlah di baris distribusi.
Akun GLN/AN/AIni adalah data baru yang diinput oleh pengguna. Pengguna memilih akun beban yang sesuai dari Chart of Accounts (Daftar Akun).
Departemen / Pusat BiayaN/AN/AIni adalah data baru yang diinput oleh pengguna. Mengalokasikan biaya ke departemen yang relevan untuk tujuan budgeting.
--- BAGIAN TOTAL & WORKFLOW ---
Pajaktax_amountSistem dapat secara otomatis membuat satu baris distribusi khusus untuk pajak, dengan jumlah yang sudah terisi. Pengguna hanya perlu memilih Akun GL untuk Pajak.
Biaya Kirimshipping_amountSama seperti pajak, sistem dapat membuat baris distribusi terpisah untuk biaya kirim. Pengguna tinggal memilih Akun GL yang sesuai.

​
Bagian 4: Hasil Akhir: Jurnal Akuntansi (The Resulting Journal Entry)

Setelah formulir Entri AP diisi dan disimpan, sistem akan menghasilkan jurnal berikut secara otomatis. Skenario:
  • Invoice dari “CV Jaya Abadi” (INV-9876)
  • Total Invoice: Rp 5.600.000
  • Rincian: Jasa Konsultasi (Rp 5.000.000) + PPN (Rp 550.000) + Biaya Lain (Rp 50.000)
Distribusi yang diinput pengguna di formulir Entri AP:
  • Baris 1: Akun GL 6100 - Beban Jasa Profesional, Jumlah Rp 5.000.000
  • Baris 2: Akun GL 2500 - PPN Masukan, Jumlah Rp 550.000
  • Baris 3: Akun GL 6200 - Beban Lain-lain, Jumlah Rp 50.000
Jurnal Akuntansi yang Dihasilkan:
No. AkunNama AkunDebitKredit
6100Beban Jasa ProfesionalRp 5.000.000
2500PPN MasukanRp 550.000
6200Beban Lain-lainRp 50.000
2100Hutang UsahaRp 5.600.000
Untuk mencatat invoice INV-9876 dari CV Jaya Abadi
Struktur ini memastikan bahwa proses entri Hutang Usaha menjadi lebih cepat, mengurangi kesalahan input manual, dan menyediakan jejak audit (audit trail) yang jelas dari jurnal akuntansi kembali ke dokumen invoice sumber.

​
Account Payable Aging

Visualizing Accounts Payable (AP) Aging is one of the most critical functions of an AP system. It helps a business manage cash flow, prioritize payments, and maintain good relationships with vendors. Let’s break down how to create and visualize an AP Aging report, starting from your datatable of unpaid invoices.

​
Part 1: The Concept of AP Aging

AP Aging categorizes your unpaid invoices based on how long they have been outstanding. The goal is to see not just how much you owe, but how urgent those payments are. The report is typically broken into time-based “buckets.” A standard set of aging buckets is:
  • Current: Invoices that are not yet due.
  • 1-30 Days Past Due: Invoices that are 1 to 30 days overdue.
  • 31-60 Days Past Due: Invoices that are 31 to 60 days overdue.
  • 61-90 Days Past Due: Invoices that are 61 to 90 days overdue.
  • 90+ Days Past Due: Invoices that are more than 90 days overdue.

​
Part 2: Data Requirements

Your datatable of AP entries must contain the following key fields for each unpaid invoice to generate an aging report.
Field NameData TypeDescriptionExample
vendor_nameVarcharThe name of the supplier.”CV Jaya Abadi”
invoice_numberVarcharThe unique invoice identifier.INV-9876
invoice_dateDateThe date on the vendor’s invoice.2023-10-26
due_dateDateCrucial Field. The date payment is due.2023-11-25
invoice_totalDecimalThe total amount of the invoice.5,600,000
amount_paidDecimalThe amount that has already been paid.0
balance_dueDecimalThe value to be aged. (invoice_total - amount_paid)5,600,000

​
Part 3: The Calculation Logic

The entire process hinges on one calculation: Days Overdue. This is calculated for each invoice relative to a specific reference date, which is usually today. Step 1: Determine the “As of” Date This is the date you are running the report for. Let’s assume Today's Date = 2023-12-15. Step 2: Calculate “Days Overdue” for Each Invoice The formula is: Days Overdue = Today's Date - Due_Date
  • If the result is negative or zero, the invoice is “Current” (not yet due).
  • If the result is positive, the invoice is past due.
Example Calculations (As of 2023-12-15):
  • Invoice A: Due Date 2023-12-20 -> 15-Dec - 20-Dec = -5 days (Current)
  • Invoice B: Due Date 2023-11-30 -> 15-Dec - 30-Nov = 15 days (Falls in 1-30 bucket)
  • Invoice C: Due Date 2023-10-25 -> 15-Dec - 25-Oct = 51 days (Falls in 31-60 bucket)
Step 3: Assign the balance_due to the Correct Bucket Using logic (like a CASE statement in SQL or an if/else block in code), you place the balance_due of each invoice into its corresponding aging bucket. Pseudocode / SQL Logic: 
SELECT
  vendor_name,
  invoice_number,
  due_date,
  balance_due,
  (CURRENT_DATE - due_date) AS days_overdue,

  CASE
    WHEN (CURRENT_DATE - due_date) <= 0 THEN balance_due
    ELSE 0
  END AS "Current",

  CASE
    WHEN (CURRENT_DATE - due_date) BETWEEN 1 AND 30 THEN balance_due
    ELSE 0
  END AS "1-30 Days",

  CASE
    WHEN (CURRENT_DATE - due_date) BETWEEN 31 AND 60 THEN balance_due
    ELSE 0
  END AS "31-60 Days",

  CASE
    WHEN (CURRENT_DATE - due_date) > 60 THEN balance_due
    ELSE 0
  END AS "60+ Days"

FROM Unpaid_Invoices_Table

​
Part 4: Visualization Methods

There are three common ways to visualize AP Aging, moving from detailed to high-level summary.

​
1. Detailed AP Aging Report (The Classic Table)

This is the most fundamental report. It lists every single unpaid invoice and places its balance in the appropriate bucket. It’s used by AP staff for day-to-day work. AP Aging Report as of: 2023-12-15
Vendor NameInvoice #Due DateDays OverdueTotal BalanceCurrent1-30 Days31-60 Days61-90 Days90+ Days
CV Jaya AbadiINV-10052023-12-20-52,500,0002,500,000
PT Sinar TechINV-7892023-11-30157,000,0007,000,000
Supplier MajuINV-SM-052023-11-10354,200,0004,200,000
CV Jaya AbadiINV-9872023-10-01751,500,0001,500,000
PT Sinar TechINV-4562023-08-151223,000,0003,000,000
------------------------------
TOTALS18,200,0002,500,0007,000,0004,200,0001,500,0003,000,000

​
2. Summary AP Aging Report (Grouped by Vendor)

This report is more useful for managers. It hides the invoice-level detail and shows the total amount owed to each vendor, broken down by aging bucket. AP Aging Summary as of: 2023-12-15
Vendor NameTotal BalanceCurrent1-30 Days31-60 Days61-90 Days90+ Days
CV Jaya Abadi4,000,0002,500,0001,500,000
PT Sinar Tech10,000,0007,000,0003,000,000
Supplier Maju4,200,0004,200,000
---------------------
TOTALS18,200,0002,500,0007,000,0004,200,0001,500,0003,000,000

​
3. Graphical Visualization (For Dashboards)

For a high-level overview, charts are extremely effective. They allow management to see the health of the company’s payables at a glance.
  • Stacked Bar Chart: This is perfect for showing the total AP balance and the proportion of that total in each aging bucket.
  • Pie Chart: A simple way to show the percentage of debt in each aging category. It quickly highlights if a large portion of your debt is severely overdue.

​
Bahasa Indonesia

​
Cara Membuat dan Memvisualisasikan Laporan Umur Hutang (AP Aging)

Laporan Umur Hutang (AP Aging) adalah alat vital untuk manajemen arus kas. Berikut adalah cara membuat dan memvisualisasikannya dari data hutang Anda.

​
Bagian 1: Konsep Umur Hutang (AP Aging)

AP Aging mengelompokkan invoice yang belum dibayar berdasarkan berapa lama invoice tersebut telah beredar (outstanding). Tujuannya adalah untuk melihat urgensi pembayaran. Laporan ini dibagi menjadi beberapa “kelompok waktu” (bucket). Kelompok waktu standar adalah:
  • Lancar (Current): Invoice yang belum jatuh tempo.
  • Lewat Tempo 1-30 Hari: Invoice yang terlambat 1 hingga 30 hari.
  • Lewat Tempo 31-60 Hari: Invoice yang terlambat 31 hingga 60 hari.
  • Lewat Tempo 61-90 Hari: Invoice yang terlambat 61 hingga 90 hari.
  • Lewat Tempo 90+ Hari: Invoice yang terlambat lebih dari 90 hari.

​
Bagian 2: Kebutuhan Data

Tabel data entri AP Anda harus memiliki kolom-kolom kunci berikut untuk setiap invoice yang belum dibayar.
Nama KolomTipe DataDeskripsiContoh
vendor_nameVarcharNama pemasok.”CV Jaya Abadi”
invoice_numberVarcharNomor unik invoice.INV-9876
invoice_dateDateTanggal pada invoice.2023-10-26
due_dateDateKolom Kritis. Tanggal jatuh tempo pembayaran.2023-11-25
invoice_totalDecimalTotal nilai invoice.5,600,000
amount_paidDecimalJumlah yang sudah dibayar.0
balance_dueDecimalNilai yang akan dihitung umurnya. (invoice_total - amount_paid)5,600,000

​
Bagian 3: Logika Perhitungan

Inti dari proses ini adalah menghitung Hari Lewat Tempo (Days Overdue). Langkah 1: Tentukan Tanggal Laporan (“As of” Date) Ini adalah tanggal acuan laporan, biasanya adalah hari ini. Misal Tanggal Hari Ini = 15 Desember 2023. Langkah 2: Hitung “Hari Lewat Tempo” Rumusnya: Hari Lewat Tempo = Tanggal Hari Ini - Tanggal Jatuh Tempo
  • Jika hasilnya negatif atau nol, invoice tersebut Lancar.
  • Jika hasilnya positif, invoice tersebut Lewat Tempo.
Langkah 3: Masukkan balance_due ke Kelompok Waktu yang Benar Gunakan logika (CASE statement di SQL atau if/else) untuk menempatkan nilai balance_due ke dalam kelompok waktu yang sesuai berdasarkan Hari Lewat Tempo.

​
Bagian 4: Metode Visualisasi

Terdapat tiga cara umum untuk memvisualisasikan Laporan Umur Hutang. 1. Laporan Umur Hutang Rinci (Tabel Klasik) Ini adalah laporan paling dasar yang menampilkan setiap invoice belum bayar dan menempatkan saldonya di kolom yang sesuai. Laporan Umur Hutang per tanggal: 15-12-2023
Nama VendorNo. InvoiceTgl Jatuh TempoLewat TempoSaldo TotalLancar1-30 Hari31-60 Hari61-90 Hari90+ Hari
CV Jaya AbadiINV-100520-12-2023-5 hari2.500.0002.500.000
PT Sinar TechINV-78930-11-202315 hari7.000.0007.000.000
Supplier MajuINV-SM-0510-11-202335 hari4.200.0004.200.000
TOTAL13.700.0002.500.0007.000.0004.200.00000
2. Laporan Umur Hutang Ringkas (Per Vendor) Laporan ini lebih berguna untuk manajer, menyembunyikan rincian per invoice dan menampilkan total hutang ke setiap vendor. Ringkasan Umur Hutang per tanggal: 15-12-2023
Nama VendorSaldo TotalLancar1-30 Hari31-60 Hari90+ Hari
CV Jaya Abadi4.000.0002.500.0001.500.000
PT Sinar Tech10.000.0007.000.0003.000.000
TOTAL14.000.0002.500.0007.000.00004.500.000
3. Visualisasi Grafis (Untuk Dasbor) Untuk tinjauan tingkat tinggi, grafik sangat efektif.
  • Grafik Batang Bertumpuk (Stacked Bar Chart): Sempurna untuk menunjukkan total saldo hutang dan proporsi setiap kelompok umurnya.
  • Grafik Lingkaran (Pie Chart): Cara sederhana untuk menampilkan persentase hutang di setiap kategori umur.