Accounts payable

Accounts payable (AP) is a company Accounting workflow. Project commitments and project payment applications are in Financials; a project action does not automatically create an AP bill.

Open Accounting > Accounts payable. A permitted user creates a bill or vendor credit, selects an allowed entity, enters the source details and codes its lines. Review the bill, submit it, and obtain the required independent approval. Payment runs and supporting payment files are available to authorized users; access is limited by company and entity permissions.

Approval routing follows the company’s approval rules. A rule can match bills or payment runs by amount, entity, project or vendor risk (new vendor, compliance hold, recently changed bank details) and route them through ordered steps: a named user, a role such as controller, the project’s team role such as Project Manager, or any of several approvers (for example any 2 of 3). With no matching rule, the amount bands in AP settings apply, and a payment run needs one releaser. An approver who is away can delegate their approvals to a colleague for a date window; the delegate acts on their behalf and the approval records both names. Nobody who prepared or edited a bill can approve it, override its holds or release its payment, directly or as a delegate, and the preparer of a run can’t release it. An owner can set up a delegation for someone else, but never to themselves. A project team role step leaves out the preparer and anyone without approval rights; if nobody is left, or a named approver prepared the bill, submitting it is refused until the rule is changed. Manage rules (an owner) and delegations under Accounting > Settings > Approval rules and delegations. An approver can Reject a pending bill or a run awaiting release with a reason: the bill goes back to draft, earlier approvals no longer count, and the preparer sees the reason under Returned to you on the Approvals page. The Approvals page lists every bill, payment run, journal entry and vendor bank change waiting for you (including those you cover as a delegate); the Approvals tab shows how many, and documents without exceptions can be approved together.

1099 review lists, for each payer entity and 1099 vendor, the year’s payments by payment date: AP payments plus checks and withdrawals written in Banking and coded to expense accounts. A banking payment counts toward its payee vendor, even when a line is job-costed to a different vendor. A banking line can be marked not reportable (materials, reimbursements). Card charges are left out because the card network reports them on a 1099-K; a withdrawal made with a debit card is also reported on a 1099-K, so mark its lines not reportable. Each entity is its own payer, so a vendor paid by two entities gets two forms and the filing threshold applies to each payer separately; filter the page by entity to see one payer. The filing exports build one issuer record per entity from the EIN and address set on the entity under Settings > Accounting entities.

Backup withholding. A payment to a 1099 vendor with no tax id on file is paid net of 24% backup withholding, credited to the backup withholding account set on the Settings tab. When the IRS sends a CP2100 notice, record each listed vendor as a B notice through the API: the first or second B notice letter is due within 15 business days, and payments from 30 business days after the notice date are withheld until the vendor cures it (a signed W-9 for a first notice; a Social Security card copy or IRS Letter 147C for a second). A user who manages vendor banking can export the year’s vendors for IRS bulk TIN Matching and import the IRS results; a vendor whose name and tax id do not match is put on a TIN mismatch hold. The Form 945 report gives each entity’s backup withholding, deposits and EFTPS deposit due dates. Set the AP policy to hold instead of withhold to stop those payments until the tax id is fixed; overriding the hold still withholds 24%.

Ready to bill on the Bills tab lists approved requisitions and approved direct costs that have no AP bill yet; Create bill drafts the bill from that source for normal review and approval.

On a posted vendor credit, apply the remaining credit to an open bill of the same vendor and entity, or undo an earlier application with an effective date. On a vendor, a user with AP approval can lift or reinstate a compliance record, including a stop pay.

When creating a payment run, the selection grid lists each payable bill with a checkbox, an editable amount for partial payment and an optional payment method; bills with an unresolved hold cannot be selected. A posted run offers buttons to download printable checks (a PDF, one check per page with two remittance stubs and the MICR line; print it on a MICR-toner printer or form that maps the MICR characters), the positive pay file and the NACHA file (a NACHA re-send asks for a reason and needs two people: one releaser or the person who prepared the run requests it, and a second releaser who neither requested it nor prepared the run confirms it; a run can be re-sent at most twice). Downloads require payment release permission and are audited.

When creating a payment run, filter the selection by entity, project or vendor and choose the bank to pay from: each active bank account you can use shows its book balance and the cash left after the run, and a bank that belongs to one entity can pay only that entity’s bills. Vendors set to ACH without approved bank details are flagged ACH not ready in the grid. The bill list shows bills awaiting approval, on hold, due within 7 days and overdue, filters by vendor, project, entity and due date, exports to CSV, and can submit the checked drafts or put the checked bills in a new payment run. A bill shows the payments that paid it and its audit trail; Payment list lists every payment. An ACH payment needs the vendor’s routing and account number on file, both when the run is created and when it is released. Release records those bank details on the payment, and the NACHA file pays that recorded account. If the vendor’s bank details change after release, generating the file is refused: void the payment and pay it in a new run. Release also re-checks pay-when-paid bills against the owner payments received at that moment. In proportional mode the sub’s entitlement is cumulative: if the owner has paid 75% of the linked pay app, the sub can have been paid at most 75% of the bill in total, counting what was already paid. A vendor credit applied to the bill lowers the bill instead of counting as a payment. A run’s checks take consecutive numbers from the pay-from bank (skipping numbers already used), and a run of a thousand payments releases in one step. Voiding an ACH payment that was already sent requires confirming that the bank recalled it; its bills then carry an ach return pending hold until an approver overrides it once the return is confirmed.

Lines marked use tax accrue tax from the bill’s tax code. Editing a draft bill’s lines or its tax code recalculates the use tax, and clearing the tax code while a line is marked use tax is refused.

ACH returns, notifications of change and prenotes. Import the bank’s return/NOC file (NACHA entries with return or change addenda) or its CSV report under the ACH notices API. A returned vendor payment is reversed on the date the return was received; its bills are unpaid again and carry an ach returned hold, and an account-level return (for example R02 account closed, R03 no account, R04 invalid account) blocks that bank account so no further ACH file pays it until the account changes. A returned direct deposit puts the employee’s net pay back in payroll cash as owed. A notification of change is queued with its due date, six banking days after receipt (Nacha Rule 2.12.1); a second person (not the one who imported it) applies C01, C02, C03 and C05 corrections to the vendor or employee bank record, and the next file uses the corrected account. C04, C06 and C07 are corrected by hand and then marked resolved. A change not applied by its due date blocks the period close. A prenote file (zero-dollar entries) covers every ACH vendor or direct-deposit employee whose current account has none; live payments to that account are refused before the third banking day after the prenote settles, and with the ACH prenote required payment control on, an account that was never prenoted is refused. The vendor profile records whether the bank account is a business or a consumer (personal) account: consumer accounts are paid in a PPD batch, business accounts in a CCD batch. The ACH monitoring report lists, for a date range, the controls in force, bank-account changes and how each was validated, returns by code and how quickly changes were applied.

A bill on a commitment is re-matched at its final approval, so a second bill against the same purchase order, or a voided receipt, is caught before posting. On a posted bill, a retainage release can be voided while the released amount is still unpaid; the reversal puts the amount back in retainage and the bill can then be voided. API clients can send an Idempotency-Key header on PO receipts, retainage releases and credit applications so a retry does not post twice.

A bill line can be marked as use tax when the vendor charged no sales tax; the bill’s use tax code then accrues the tax. On a job whose tax profile makes the contractor the consumer of materials (for example California), a line with tax category material defaults to use tax at the job’s use tax code unless the line says otherwise, so an untaxed material bill accrues use tax without a manual step. Set the line’s use tax off when the vendor did charge sales tax.

A spoiled or lost check can be reprinted through the API (ap/checks/{id}/reprint): the old check number is voided in the check register (and sent as a void on the next positive pay file) and the same check is issued under the next number. The payment itself is unchanged.

An unconditional lien waiver can name the AP payment it covers. It then counts for that payment only, and if its amount is less than what that payment paid on the project, it is kept on file but does not clear the lien waiver hold. Compliance requirements (ap/compliance_requirements) make a document kind, such as a license or COI, mandatory for every vendor, one vendor or the vendor on one commitment; a bill is held as compliance missing until a current record is on file. A hold override can carry an expiry date, after which the hold applies again. Each day, users with AP rights get an email listing vendor compliance documents that expire in 30 days, in 15 days or today.

The Receipts tab records quantities received against unit-priced purchase order lines and voids receipts. The Settings tab (chart of accounts permission) holds approval bands, matching tolerances, the over-commitment rule, lien waiver mode, receipt accrual and its received-not-invoiced account, discount posting, the default pay-from bank, the bank-detail change cool-off and ACH origination details. Approval bands, the cool-off (at least 3 days), the ACH company id, the ACH destination routing and ACH prenote required are payment controls: only an accounting owner can change them, and each change is recorded with its before and after values.

The vendor page’s Accounting profile panel sets the payment method, 1099 reporting and form, W-9 status and tax classification, terms, retainage and remit-to address, and shows the tax id and bank account masked to the last 4 digits; a user who manages vendor banking can reveal the full numbers, which is audited and rate limited. A vendor’s tax id or bank details change only after a second person approves, from the same panel or the Approvals page. Bank details are entered by AP users or users who manage vendor banking. The approver sees the last 4 digits of the old and new numbers and approves that exact request. If someone enters a new request before the approval, the old one is replaced and the approver has to review the new values.

Saved draft or pending bills can be corrected through the edit workflow. Editing a submitted bill resets its approval progress. If another user has changed the bill, reload and review before saving again. API bill updates require the last-read expected_revision; a stale revision is rejected.

Posted bills require the supported source correction or reversal flow. Retainage and related reports should be reviewed separately before close. No action here transfers money by itself. See Accounting overview and Security and controls.