Product
The column your team needs that no PO template has
The side spreadsheet exists because the purchase order has nowhere to put what your team actually tracks. The fix is knowing which facts belong on the order, and keeping them there from the draft to the dock.
The spreadsheet next to the PO system
A standard purchase order is built to answer a narrow set of questions: what item, how many, at what unit cost, for what total, requested by when, and whether it has been received and invoiced. Those fields are the same for every business, which is exactly why a template can ship with them.
What a template can't know is everything else. An importer tracks a container number and a booking reference, because those are what the freight side recognizes, not the PO number. A team buying overseas watches whether the deposit has gone out and when the balance falls due. Someone records the inspection result. Someone else keeps an internal arrival date that differs from the date the supplier promised, because leaving the factory and landing on your shelf are not the same day.
None of that has a column, so it goes into a spreadsheet next to the PO system, keyed by PO number and maintained by whoever remembers. The spreadsheet isn't the problem. The problem is that it's a second record of the same order, and the two drift apart the first time someone updates one and not the other.
Is it true of the supplier, or true of this order?
Before adding any column, ask one question of the fact: would it still be true on the next order from this supplier?
If yes, it's a standing fact, and it belongs on the supplier. In Assisty, that's where Lead Time, Reorder Cycle, Min Stock Cover Days, and order minimums and maximums live, set once so the buying table's suggested quantities use them automatically, with per-variant overrides for supplier SKU, cost, minimum order quantity, and case quantity. Currency and contact details sit on the same supplier record.
If no, because it describes this shipment and will be different next time, it belongs on the order. The container reference, the deposit status, the QC result, the internal ETA: each describes one PO and nothing else.
A placement test, not a list of product fields.
| Fact | True of | Where it belongs | What goes wrong if it's misplaced |
|---|---|---|---|
| Lead time | The supplier | Supplier record | Re-keyed on every PO; the orders end up disagreeing about the real number |
| Minimum order quantity, case quantity | The supplier (or one variant from them) | Supplier record, per-variant override | Suggested quantities stop matching how the supplier actually sells |
| Currency, contact details | The supplier | Supplier record | Copied by hand, and wrong on the order where it matters |
| Container / booking reference | This order | Custom column on the PO | Parked on the supplier, it's right for one shipment and stale for every one after |
| Deposit / balance status | This order | Custom column on the PO | Tracked in a side sheet the person releasing payment may never open |
| QC result | This order | Custom column on the PO | Separated from the payment it should gate |
| Internal ETA | This order | Custom column on the PO | Mixed up with the supplier's promised date, so lead-time drift goes unnoticed |
Both mistakes are expensive, in different ways. Put a per-order fact on the supplier and it goes stale. Put a standing fact on the order and it gets re-keyed on every PO, which means it will eventually be keyed differently, and the supplier's real lead time ends up scattered across orders that disagree with each other.
Four columns worth adding
The test for a custom column isn't whether the information is interesting. It's whether one person writes it at one stage of the order and someone else needs it at a later one. If the same person writes it and reads it the same afternoon, it's a note, not a column.
Generic roles. Your team's names for them will differ.
| Column | Written by | When | Needed later by |
|---|---|---|---|
| Container / booking reference | Whoever books the freight | Once the goods are ready to ship | Receiving, to match the delivery to the order |
| Deposit / balance status | Finance or the buyer | At order, and again before shipment | The buyer, before releasing the goods |
| QC result | Whoever reviews the inspection | Before shipment | The buyer (to release the balance) and receiving (what to check) |
| Internal ETA | The buyer | Updated as the shipment moves | Receiving, to plan the dock; the buyer, to judge whether the lead time still holds |
The deposit and QC columns belong together on purpose. Pre-shipment inspection usually comes before the balance payment, so a failed inspection lands at the point where you still have leverage. That only works if the QC result and the payment status sit on the same order, where the person releasing the money can see both.
A value is worth more at receiving than in a tidy sheet
Look at the last column of that table. Almost every value is written early and read late. The container reference matters to whoever is matching a delivery to an order. The QC note matters to whoever is deciding which cartons to open and count. The internal ETA, compared against the day the PO went out, is the evidence for whether the supplier's lead time still deserves the number on its record.
That's the real case against the side spreadsheet, and it isn't about tidiness. The buyer opens the spreadsheet; the receiving team opens the PO. A fact that lives only in the buyer's sheet is missing at exactly the moment it pays off. A custom column earns its place only if it survives the whole trip, from the draft to the receipt, instead of falling off when the order changes state.
Where the columns ride in Assisty
Assisty treats a purchase order as a lifecycle rather than a draft. You select rows in the buying table and create orders on the spot, or add them to the Purchase List, which holds items priced with each supplier's tax and currency until you've finished reviewing; nothing is committed until you create the order. When you do, Atlas splits the selection into one PO per supplier and asks which location receives the stock, and each draft is seeded from suggested quantities.
From there you review the line items, email the PO to your supplier, and receive against it when stock arrives, with tax types, landed-cost allocation, and your own custom columns carried through every step.
That makes the placement rule practical. Standing facts go on the supplier, where the suggested quantities read them. Facts about this shipment go in custom columns on the order, where they stay attached from the draft to the dock.