Purchasing
Purchase orders, supplier records, goods receipt and accounts payable for MSPs and the clients they buy for — with the approval and the three-way match in the same system as the ticket that caused the spend.
The problem
Somebody needs a laptop. It gets ordered from a distributor portal, the PO number lives in an email thread, and the confirmation goes to one person’s inbox. Six weeks later the supplier’s invoice arrives and nobody can say whether the price matches what was quoted, whether all four units actually turned up, or who authorised $9,000 of hardware in the first place. The answer is in a spreadsheet, an inbox and somebody’s memory, and finance is closing the month tomorrow.
If you are an MSP it is worse: you are buying on behalf of clients who are separate businesses with separate books, and the same supplier invoice may carry lines for three of them.
What Solidlio does about it
Purchasing runs the whole path in one place: create the supplier, raise the order, route it to whoever is allowed to approve that amount, email it to the vendor, receive the goods against the order’s own lines, then match the supplier’s invoice back to the order it came from. Approval is a recorded fact — a decision row written in the same database transaction as the status change, so an order cannot be approved without a record of who approved it and for how much. The three-way match compares the invoiced quantity and unit price against the purchase order and flags anything above tolerance for a human. Each client is a separate account with its own books, and every query is scoped to the account that asked.
Capabilities
| Capability | What it does |
|---|---|
| Supplier records | Create, approve, edit and retire vendors with payment terms, tax id and account number. New suppliers are never auto-approved. |
| Purchase orders | Nine-state lifecycle from draft to closed, with server-computed totals, freight, ship-to and per-line expense coding. |
| Amount-based approval rules | Ordered, multi-step workflows selected by the order total, each step routed to a named user, a role or a group. |
| Enforced approver | Only the approver a step is assigned to can decide it. Anyone else is refused; delegation is explicit and recorded. |
| Vendor dispatch | Emails the order to the supplier, branded as the tenant they deal with, and marks it sent only when the mail was accepted. |
| Partial receipt | Receive per line, cumulatively, in quantities to four decimal places. Over-receipt is refused with the outstanding amount quoted. |
| Goods receipt sessions | Book stock into a location with packing slip, serial numbers and MAC addresses; turn a received line into a tracked asset. |
| Accounts payable | Supplier invoices with line-level expense coding, private document storage, partial payments and derived balances. |
| Three-way match | Matches each invoice line to its PO line by SKU then MPN, and flags a quantity overage or a unit price more than 1% above the order. |
| AI document capture | Extracts a supplier invoice from a PDF into header and lines; AI match suggestions apply only at 0.7 confidence or above. |
| Audit trail | Every approval, rejection, receipt, cancellation and payment is appended to the record, never overwritten. |
Built for MSPs and their clients
A managed client is a separate account with its own books, not a sub-record of the MSP. Purchasing respects that in both directions.
| Organization (the client) | MSP | |
|---|---|---|
| Raising an order | Buys for itself. A standalone account with no MSP staff runs its own purchasing end to end. | Raises orders naming the client organization it is buying for. |
| Approving spend | Its own administrator approves its own orders. | Its administrators approve MSP orders. A technician can order but never approve. |
| Approval rules | Configures its own thresholds and approvers. | Configures its own. Platform-wide rules are visible to both and editable by neither. |
| Suppliers | Its own vendor records, plus the shared platform vendors. | Its own. A shared vendor cannot be edited by any tenant. |
| Accounts payable | Its own bills, its own ageing. | Its own bills and its own ageing. |
| Cross-tenant visibility | None. | None. Another account’s purchase order is not found, not forbidden. |
How it works
- Add and approve the supplier. A new vendor is created unapproved. Approving it is a separate act by an administrator.
- Raise the order. Line items carry quantity, unit price, tax, SKU/MPN and an expense category. Totals — including freight — are computed server-side from the lines.
- Submit it. Solidlio selects the approval workflow whose amount range covers this order’s total, preferring the account’s own rules over platform-wide ones, and creates the step-1 approval assigned to the configured approver. If no rule matches, the order still waits for a human — it is never auto-approved. If the rule routes to nobody, submission is refused so the rule gets fixed.
- The approver decides from the approvals queue. The decision is written with the amount, the decider and the timestamp in the same transaction as the status change.
- Send it to the vendor. The order is emailed with every line and the total. It is marked sent only if the email was accepted; a failure leaves it approved and retryable rather than falsely dispatched.
- Receive the goods, either as a quick per-line acknowledgement or as a full receiving session that books serialised stock into a location and can create assets.
- Enter the supplier’s invoice, by hand, from an inbound AP mailbox, or by AI extraction from a PDF.
- Match and pay. Matching links each line back to the order; variance is flagged. After approval, record full or partial payments — the balance is recomputed in integer cents from the total and what has been paid, so an overpayment is refused rather than absorbed.
Compliance and audit
Every spend decision is a row, not a flag. A purchase order or supplier invoice approval records the approver, the approver type, the step it belonged to, the workflow it came from, the decision, the comments, the timestamp it was requested and the timestamp it was answered — and the money involved is written into the record, because the document total stays editable in the states before approval and a bare foreign key would not say what was approved.
The approval record and the status change are written in a single transaction. A document sitting in “pending approval” with no approval row, or approved with no record of who approved it, cannot occur.
Rejections record the reason, the rejector and the time as first-class columns. Cancellation, voiding, receipt and payment notes are appended to the document’s internal notes rather than replacing them, so the history of an order survives every later action taken on it.
Approval authority is enforced per approval, not per role: being an administrator in the right tenant does not let you decide an approval assigned to somebody else. Handing it on is possible and is itself recorded — the original step is marked skipped and the new one carries who delegated it.
Editions
Purchasing is included in every plan, including Free. There is no feature flag for purchase orders, vendors, accounts payable, matching, receiving or approval workflows, and no plan gate anywhere in it.
Two adjacent limits apply: creating a hardware asset from a received line counts against the plan’s asset limit, and AI-assisted invoice extraction consumes AI credits.
Integrations
- QuickBooks Online — approved purchase orders sync as QuickBooks purchase orders and approved supplier invoices as bills, with vendor mapping.
- GLPI — supplier directory synchronisation.
- Solidlio AI — supplier-invoice extraction from PDFs and match suggestions.
Distributor catalogue, pricing and stock feeds from Ingram Micro and TD Synnex populate the product catalogue that invoice lines match against. Order transmission to a distributor is not part of this release — purchase orders go to the supplier by email.
The order, the receipt and the invoice should agree before anyone pays.