Purchase Orders¶

Overview¶

Purchase orders commit spend with a vendor for specific goods or services. They record the approved obligation, the charge lines that make up that obligation, and how related payables draw that commitment down.

Use purchase orders when the work is one-off or project-specific — for example a roof replacement, parking lot repaving, or elevator modernization. Recurring services, insurance, taxes, and other ongoing obligations belong on other vendor contract types.

Credence manages two purchase-order surfaces:

Development purchase orders share the same purchase-order model and change-order workflow. They are listed and navigated under Development rather than the Purchase Orders page.

Definitions¶

Rules and Behavior¶

Creating a purchase order¶

A purchase order needs a vendor, currency, and at least one charge line before it can be approved. You can also set:

• Description and executed date
• PO number — system-generated as year.NNNN when left blank
• Parent service contract — a drafted or active service contract
• Project — an active child or standalone CapEx/OpEx project (not a parent project that only organizes children)
• Escalation fields when the commercial terms call for them

Draft vendors and parent service contracts can be selected before they are approved. Submission and every approval step require approved, active parents.

You can start a purchase order from a project, a service contract, or a vendor. Starting from a development job marks the PO as development-affiliated and routes it under Development Contracts.

Charge lines¶

Each charge line carries the obligation for a property:

• Property, expense account, and amount are required for approval
• The expense account must belong to that property's chart of accounts
• Start and end dates define the charge schedule. Marking a charge One-time keeps the end date equal to the start date
• An operational charge may optionally reference a CapEx or OpEx project
• A development charge must include both the job and a cost code from that job property's Cost Breakdown Structure

You can split a charge across properties before or while editing the PO. Split methods and rules are covered in Vendor Contracts.

Development purchase orders¶

A purchase order is development-affiliated when its header project is a development job or any charge line is coded to a development job.

Credence checks development coding when the PO is saved and again before approval:

• Each development charge must use the job's property
• The cost code must come from that property's Cost Breakdown Structure
• When the job has a configured account, the charge must use that account
• When the job has no configured account, the charge account can change after payables are linked only if it matches every active approved non-tax payable line (cancelled, rejected, and tax lines do not restrict that change)

Development purchase orders are also checked against job × cost-code Available budget before approval. See Calculation Details. Cost-code budget blocking applies only to development purchase orders, not to operational POs or other vendor contract types.

Approval and statuses¶

Approval requires:

• An active vendor (and no vendor activity block)
• Currency and at least one complete charge line
• No duplicate approved purchase order with the same PO number and vendor
• An active parent service contract, when a parent is set
• Project budget availability when the PO header has a project (see Calculation Details)
• Development coding and cost-code budget checks when the PO is development-affiliated

If an approval workflow is configured for the applicable portfolios, the purchase order follows its role-based steps. If no workflow applies, an authorized user can approve it directly.

On approval, the purchase order becomes Approved / Active.

Editing after approval¶

After approval, day-to-day edits are limited to informational fields:

• On the purchase order: description, executed date, and documents
• On charge lines: description

The system-generated name and PO number are not informational fields. Amount, coding, vendor, currency, project, and parent changes are controlled. Changing those after approval requires the permission to edit approved purchase orders, or a change order for amount and new-line proposals.

Closing and reopening¶

Close an approved, active purchase order when no further work or charges are expected. Closing sets committed amount to $0 even if unspent balance remains on the contract total.

You can reopen a closed purchase order when you have change permission on it.

Credence may notify the purchase order's creator when recorded spend reaches 97% of the total contract amount on an approved, active purchase order with a positive total. That notification is a recommendation only; close the PO manually when no further work is expected.

Payables and ledger impact¶

Match vendor invoices to the purchase order so spend reduces remaining commitment and supports budget reporting.

• The payable's vendor must match the purchase order's vendor
• Related payables and ledger bundles appear on the purchase order detail page
• Ledger posting flows through payables and bookkeeping; the purchase order itself does not post ledger entries

Change orders¶

Change orders record proposed amount changes to an approved, active purchase order. The approved PO remains the source of truth until the change order reaches final approval.

You can add a change order when:

• The purchase order is approved and active
• The contract type is purchase order
• No purchase-order workflow steps are pending
• You have permission to change that purchase order

Change orders use the parent purchase order's view and change permissions; they do not use a separate change-order permission.

A change order carries a change order number, a date, a short reason, and longer notes. Credence prefills the number as {PO number}-CO-NN based on the purchase order's existing change orders. The date controls the order in which change orders appear on the purchase order.

What a change order can propose¶

• Change the amount of an existing charge, including reducing it to zero. Coding on existing charges stays read-only. A zero proposed amount keeps the charge on the PO with a zero balance after approval
• Add a new charge line. Operational lines need property, project (when used), expense account, and amount. Development lines need job, cost code, expense account, and amount; property comes from the selected job
• Optional description per adjusted or added line. For an added line, that description becomes the new charge's description after approval

Approval and impact¶

• Starting approval makes the change order read-only until it is withdrawn, returned, rejected, or approved
• After final approval, the reason, notes, documents, and line descriptions remain editable; amounts and coding are fixed
• Hold and deny do not change the purchase order. Withdrawal or return to the submitter makes the draft editable again
• Rejected change orders remain in history and never change approved charges
• Credence validates every affected line before approval can start and again at final approval. If any line is invalid, approval is blocked and none of the changes apply
• A development change order cannot be approved when its changes would take any job × cost-code budget past Available plus the portfolio's budget tolerance
• Final approval creates each proposed new line as a live purchase-order charge and applies amount changes to existing charges

Pending (draft or in-approval) proposals do not affect the purchase order total, committed amount, project or job budget availability, or payable matching. Those values change only after final approval.

Before approval, change-order pages show purchase-order impact, related budget impacts (job × cost-code for development), and each line's initial and proposed final amounts. After approval, those projections are hidden because the live PO and budgets already reflect the change; approved history shows each line and its net change.

Change-order documents uploaded while drafting stay on the change order. They appear in the purchase order's combined Change Orders document group only after approval.

On an approved change order, More Actions includes Generate Document. Choose a Change Order template. Credence fills it from the change order and the parent purchase order, then stores the PDF on the change order. That file appears in the purchase order's Change Orders document group with the change order's other documents. Draft and rejected change orders cannot generate a document. A Change Order template must be configured before generation can succeed.

Calculation Details¶

Contract amounts¶

Total contract amount = sum of charge-line amounts on the purchase order

Purchase orders use a fixed-amount model: each charge defines a total commitment, not a per-payment recurring amount.

Start date / end date on the purchase order are the earliest charge start date and latest charge end date.

Spend, invoiced, and committed¶

Total spend = spend on payable charge items tied to this purchase order's charges, including spend on child contracts when the PO is a parent

Committed = max(Total contract amount − Total spend, 0)

Special cases:

• Closed purchase orders report Committed = $0
• If spend exceeds the contract amount, Credence floors committed at $0 rather than showing a negative

Invoiced is the sum of approved invoice amounts on the purchase order's charges. Draft invoice amounts appear separately as drafted totals on the detail view and do not reduce committed.

Project and job budgets¶

Operational purchase orders with project-coded charges show budget cards at project grain. Development purchase orders show budget cards at job × cost-code grain.

For CapEx/OpEx projects:

Available = Current Budget − Invoiced − Committed

Where project Committed is the remaining unspent obligation from project-scoped purchase orders and other committed sources. See Projects.

When a purchase order has a header project, approval is blocked if that project's available budget (including the portfolio's budget tolerance) cannot cover the contract amount.

For development jobs:

Available (at job × cost code) = Current Budget − Spent − Approved Spend − Committed

Approval of a development purchase order or development change order is blocked when the projected commitment would take any job × cost-code line past Available plus the portfolio's budget tolerance. A line with no current budget does not block. A portfolio without a budget tolerance limit is never blocked on budget. See Jobs.

Example¶

Assume an approved, active purchase order:

Credence shows:

• Committed = $40,000 − $10,000 = $30,000

If that PO is closed, Committed becomes $0 even though $30,000 was never spent.

When the same $40,000 obligation is coded to a CapEx project or a development job × cost-code line, Credence reserves the remaining commitment against that budget's Available amount (see Projects and Jobs). Approving an additional $50,000 purchase order against a line with only $30,000 Available is blocked when the portfolio's budget tolerance does not cover the overrun.

Common Scenarios¶

• A property manager creates an operational purchase order for a roof replacement, ties charge lines to a CapEx project, submits it for approval, then matches invoices to the PO as work is billed.
• A development project accountant creates a development purchase order from a job, codes each line to a leaf cost code, and cannot approve until every line fits within job × cost-code Available (plus portfolio tolerance).
• After an approved PO is active, a project manager drafts a change order to increase one charge and add a new line for unforeseen work. Budget and committed amounts stay unchanged until the change order is fully approved.
• A controller closes a purchase order after spend reaches nearly the full contract amount and no further invoices are expected, so committed returns to $0 on budgets and reports.
• An asset manager links a one-off landscaping PO under an active parent service contract so related vendor activity stays grouped for reporting while the PO itself remains a fixed commitment.