Accounts Payable

Accounts Payable mirrors Accounts Receivable on the other side of the books: instead of they owe us, we collect, it's we owe them, we pay. The mechanical model is the same — journal entries with extra metadata, applied via the payment_applications table — just with the debit/credit sides flipped.

If you've read the AR doc, the AP doc is shorter; we'll lean on the AR explanations and call out only the differences.

Vendors

Vendors are stored in the same contacts table as customers — with contact_type = 'vendor'. The fields are identical: display name, email, phone, default payment terms, default account, currency, credit limit, active flag, encrypted TIN.

Two vendor-specific bits matter for AP:

  • is_1099_eligible — flag the vendor if you'll need to issue them a 1099 at year-end. Most contractors and unincorporated businesses you pay over $600/year are 1099-eligible. Corporations generally aren't.
  • TIN + tax_id_type — store the vendor's tax ID (SSN, EIN, SIN) so it appears on the 1099. Stored AES-256-encrypted at rest; only the last 4 digits show in the UI by default.

A contact can be both customer and vendor — set both flags on the contact_type. Common with co-ops or parties you trade both directions with.

Bills

A bill is a journal entry of transaction_type = 'bill' with a vendor attached. Posting a bill produces:

DR  Expense (per line, on the line's account)
CR  Accounts Payable                    total

The expense side splits per line — different categories of spend (rent, software, utilities) post to different expense accounts. AP is one posting per bill for the total.

Bill fields

  • Bill number / reference number — the vendor's invoice number to you, used for matching
  • Date — the bill date (when the vendor issued it); drives fiscal period
  • Due date — derived from the vendor's payment terms or set explicitly
  • Vendor — required
  • Line items — one or more, each on its own expense account
  • Tax — sales-use tax codes apply on the AP side too, where relevant
  • Memo, currency, exchange rate, custom fields — same as invoices

Status flow

Same as invoices: draftpostedreversed / void. Draft bills don't affect the GL or AP aging; once posted, they show on the vendor's open balance and on AP aging.

Pay Bill

When you pay a vendor, you record a Pay Bill — a journal entry of transaction_type = 'pay_bill'. The GL effect:

DR  Accounts Payable
CR  Bank

That clears the AP balance. The same payment_applications table that links Receive Payments to invoices also links Pay Bills to bills — partial payments, multi-bill payments, and unapplied prepayments all work.

Common cases

CaseWhat you record
Pay one bill in fullPay Bill, applied to one bill
Pay several bills with one checkPay Bill, applied to multiple bills
Pay part of a billPay Bill, partial application; bill stays open with remaining balance
Vendor prepayment / depositPay Bill with no application; sits as unapplied credit on the vendor
Pay via credit cardSame as above but CR Credit Card instead of CR Bank

Pay Bills batch

Most accounting workflows have a Pay Bills dialog: pick the date, see all unpaid bills due (or past due), check off which ones to pay, choose the payment account, generate one Pay Bill entry per check. Solid's Pay Bills dialog produces a series of individual pay_bill entries — one per check or transfer — so each check on your bank statement matches one entry on reconciliation.

Vendor Credits

A vendor credit is the AP-side mirror of a customer credit memo — a journal entry of transaction_type = 'credit_memo' with a vendor attached. The GL effect:

DR  Accounts Payable
CR  Expense (or specific reversal account)

Use cases:

  • Vendor refund for an overcharge or returned item
  • Promotional credit the vendor issued you against a future order
  • Posting error correction (a bill was overstated; vendor agrees)

Vendor credits can be applied against open bills (reducing the AP balance) or held as a credit balance with the vendor (offset against future bills).

AP Aging

AP Aging buckets every vendor's open balance by how overdue you are:

BucketMeaning
CurrentNot yet due
1–30 days1–30 days past due
31–60 days31–60 days past due
61–90 days61–90 days past due
Over 90More than 90 days past due

Same structure as AR Aging, opposite direction. AP Aging is the report you run when planning cash outflows and deciding what to pay this week vs. next.

The "Current" bucket is the one to pay close attention to — bills due soon. Late-paying vendors damages relationships and (for some industries) puts you in violation of supplier terms.

1099 Tracking and Filing

The is_1099_eligible flag on vendors drives the 1099 report at year-end. Solid tracks every payment to flagged vendors throughout the year; the 1099 report aggregates by vendor and by 1099 box (NEC, MISC, etc.) at year-end.

What's tracked

  • All payments on transaction_type IN ('check', 'pay_bill') to flagged vendors
  • Box assignment: configurable per vendor (default to Box 1, Nonemployee Compensation, on Form 1099-NEC)
  • Excluded by IRS rule: payments by credit card or third-party network — those get reported separately by the processor on Form 1099-K. Solid filters them out automatically when computing 1099 totals.

What you do at year-end

  1. Run Reports → 1099 Report for the calendar year
  2. Review by vendor — confirm names, addresses, and TIN are correct (Solid surfaces missing TINs as red flags)
  3. Export the data to your filing service (Track1099, Tax1099, etc.) or to PDF for paper filing
  4. File with the IRS through FIRE/IRIS or a service that does it for you

Solid surfaces what to file. The actual filing happens through the IRS or a service. We deliberately don't run the filing ourselves — that's a separate compliance and licensing surface we're not in.

Common gotchas

Vendor's bill number doesn't match what's in Solid. The bill's reference_number field is the vendor's invoice number to you — store theirs there, not yours. The internal entry_number (auto-generated like JE-00042) is Solid's identifier; keeping the vendor's number on the bill makes reconciliation later painless.

1099 totals are off by a credit-card payment. Correct — the IRS requires excluding credit-card payments from 1099-NEC totals because the card processor reports them separately on 1099-K. If a vendor sees their 1099 total and asks "what about the card payment?", that's the answer.

Pay Bill posted to wrong account. Easy to get the bank account wrong on a Pay Bill (chose Operating instead of Credit Card). Reverse the original and re-post; the Pay Bills dialog will show the bill as open again.

A vendor credit isn't reducing the next bill total. Credits don't auto-apply — you apply them when recording the next Pay Bill. The vendor's open balance shows the net (bills minus credits) but the Pay Bill dialog applies them explicitly so you can choose which bills the credit offsets.

Bill posted to current period but vendor backdated it. Edit the date on the draft, or — if already posted — reverse and re-post with the correct date. The fiscal period the bill posts to follows the date, not the entry timestamp.

Cross-references