Skip to main content
DELETE
Void a vendor bill

Authorizations

Authorization
string
header
required

API key issued per entity via Settings > Developers > API Keys. Each key carries scopes (e.g. orders:read, products:write). Bearer token format: Authorization: Bearer ark_live_ent_Test keys use ark_test_ent_. Both are issued per entity
via Settings > Developers > API Keys.

Path Parameters

id
string<uuid>
required

Response

Voided vendor bill

A vendor invoice (AP). Posts to AP and inventory/expense on approval.

id
string<uuid>
object
enum<string>
Available options:
vendor_bill
entity_id
string<uuid>
read-only
bill_number
string
read-only

Sequential bill number per entity.

vendor_invoice_number
string | null

Vendor's invoice number.

vendor_id
string<uuid>
po_id
string<uuid> | null
status
enum<string>
read-only
Available options:
draft,
pending_approval,
approved,
rejected,
paid,
partially_paid,
voided
bill_date
string<date>

The vendor's document date.

effective_date
string<date>

The posting date: the date the bill's journal entries post to the general ledger and the anchor of its due date. Defaults to bill_date. It may be ahead of or behind bill_date inside the entity's posting-date window (Settings > Fiscal Year); a posted bill's posting date moves only through a linked pair of correcting entries, never by editing this field.

posted_entry_date
string<date> | null
read-only

The date of the bill's own journal entry (returned by GET /v1/vendor_bills/{id}).

ledger_posting_date
string<date> | null
read-only

The date the bill's liability sits on in the ledger now, which follows a posting-date correction (returned by GET /v1/vendor_bills/{id}).

redate_block
object | null
read-only

Null when the bill's posting date can still be moved; otherwise why not, as the re-date door would refuse it (for example bill_terminal for a voided bill). Returned by GET /v1/vendor_bills/{id}.

redate_latest_date
string<date> | null
read-only

The latest date the bill's posting date may move to: the first day money or credit relieved the bill (a posted payment, an applied vendor credit, an applied prepayment), so the vendor's payable never runs negative in between; null when nothing has relieved it. Returned by GET /v1/vendor_bills/{id}.

posting_corrections
object[]
read-only

Every posting-date correction of this bill, newest first. Each is a linked pair of CORRECTION journal entries: the OUT leg removes the liability from from_date and the IN leg records it on to_date. At most one pair is live (the one carrying the liability now). Returned by GET /v1/vendor_bills/{id}.

due_date
string<date> | null
subtotal
number
tax_total
number
shipping_total
number
bill_total
number
amount_paid
number
read-only
balance_due
number
read-only

bill_total minus amount_paid. Unlike the sales-side orders.balance_due, this is NEVER coerced to 0 by document lifecycle: a draft or terminal vendor bill still reports its true remaining payable. There is therefore no separate amount_due field on this resource. SSOT: utils/ap-helpers.mjs::updateAPBalance.

currency
string
default:USD
payment_term_id
string<uuid> | null
notes
string | null
metadata
object | null
created_at
string<date-time>
read-only
updated_at
string<date-time>
read-only
landed_receipts_reached
object[]
read-only

Every receipt the bill's landed allocations reached, in all three modes (Case A, a landed-only bill naming a PO, a receipt set); allocated_amount only for a caller with the margin permission (never an API key today). Returned by GET /v1/vendor-bills/{id}.