Payments & "marked as paid"

A PO can carry many payments — deposit plus final payment, multiple wire transfers, mixed currencies. The “marked as paid” flag is operator-set, not auto-derived. This page is the small but important reference for payment workflows.

Recording a payment

From the Payments card on the PO detail page, click Add Payment. Fill in:

Net Amount and Currency (both required).
Exchange Rate — shown only when the currency differs from your shop currency.
Payment Method — Bank Transfer, Wire Transfer, Credit Card, Debit Card, PayPal, Cash, Check, Letter of Credit, Cryptocurrency, or Other.
Payment Terms.
Transaction Number (the bank reference or your AP system’s number) and Status — Initiated (the default), Pending, Completed, Failed, or Rejected.
Invoice Number, Due Date, and an optional link to an already-uploaded Invoice Document.
Tax and Tariff — pick a configured tax rate or a duty preset and Logistified derives the amount from the percentage, or type the amount in directly.
Notes.

There is no separate “payment date” field — Logistified stamps the date from the status you save the payment with.

Save. The Payments card lists every payment and shows the total underneath.

Multi-payment

Many payments per PO are supported. Useful for deposit + final workflows, or for tracking partial settlements over time.

The “marked as paid” flag

The Payments card has a Mark as fully paid checkbox (the same control appears in the PO edit dialog under Payment Status). Important to understand:

It’s operator-set, not automatic. Setting it to “paid” doesn’t validate against the recorded payments total. Setting it to “not paid” doesn’t reverse payments.
It’s a reporting marker, not a financial source of truth. Your finance team’s books are authoritative.
Useful when payment reconciliation happens outside the app — in your bank statement reconciliation or your AP system.

So you can have a PO with zero recorded payments but marked as paid (because you reconciled it elsewhere), or a PO with payments summing to the total but not marked as paid (because you haven’t finished reconciling). Both are valid states.

Counting payment tax and tariff toward paid status

Besides the operator flag, recorded payments also drive the paid status: when your completed payments cover the order’s item total — unit cost × quantity across the line items, so shipping, additional costs and order-level tax are not part of the comparison — the PO reads as fully paid. Each payment row can carry a tax and a tariff amount alongside the main amount, and a setting decides whether those count:

Off (the default): only the payment Amount counts toward the total. This is the right mode when you record gross, tax-inclusive figures in the Amount field — counting the tax field on top would double-count the tax.
On: each payment counts as amount + tax + tariff. Turn this on when you record net amounts with the tax entered separately, so a net payment plus its tax still marks the PO fully paid (and stamps the Fully Paid Date) once the order total is covered.

The toggle lives at Settings → Purchase Orders → Preferences → “Count recorded payment tax and tariff toward the paid status.” It affects the Paid badge, the paid/unpaid filter, and when the Fully Paid Date is auto-set — pick the mode that matches how you fill in the payment dialog. One exception: the purchase-order CSV export’s amount-paid, outstanding, and paid-status columns always sum the payment Amount fields only (net), regardless of this setting.

Fully Paid Date

The PO edit dialog includes a Fully Paid Date field. It records when full payment was actually settled. It is auto-set the first time the PO becomes fully paid — when you tick “Mark as fully paid,” when recorded payments add up to the total, or, if your shop has Auto paid when completed turned on, when the PO reaches Completed — and it is never cleared or overwritten automatically. The auto-set only fills an empty field; a date that’s already there stays put. You can set, change, or correct it by hand.

When a Fully Paid Date is recorded, it shows next to the paid badge: the Payments card shows a “Fully paid” badge followed by “on [date],” and the Financial Summary on the order information card shows a “Paid” badge followed by “on [date].”

Due Date and the payment-due badge

The PO edit dialog also has a Due Date field — when payment is due. Logistified derives it from the payment terms:

Picking a supplier or payment terms fills an empty Due Date automatically. Net N terms (e.g., Net 30) add N calendar days to the base date — the day the PO was sent, or today for a PO that hasn’t been sent yet. Due on Receipt, Cash in Advance, and Cash on Delivery use the base date itself; End of Month uses the last day of the base date’s month. No terms, or Custom, derives nothing.
Changing the Shipping Date re-derives the due date from the same terms, counted from the new shipping date.
Derivation never silently overwrites: if a different due date is already set, Logistified asks before replacing it, and when the payment terms and the shipping date imply two different due dates, it asks which date to count from. Clearing the shipping date never clears a due date.

You can also edit the Due Date by hand to override any derived value. The field is editable while the PO is in flight; it locks once the PO is Received, Completed, On Hold, Disputed, or Cancelled.

While the PO is not yet fully paid, the Due Date drives a status badge on the Payments card and the Financial Summary row of the order information card (compared by calendar day in your local timezone):

Badge	When it shows
Outstanding payment (red)	The due date has passed
Pay today (yellow)	The due date is today

A due date in the future, or no due date at all, shows no badge — the Financial Summary falls back to its plain “Unpaid” badge, and the Payments card simply shows no payment badge at all until the date becomes actionable. The PO list doesn’t show this badge. Once the PO is fully paid, the badge is replaced by the paid indicator above.

Currency

The PO’s line items use one currency, inherited from the supplier. Payments are more flexible — each payment can be recorded in any currency, and Logistified converts it to your shop’s currency using an exchange rate per payment.

When you add a payment in a currency different from your shop’s currency, the dialog shows an Exchange Rate input. Logistified attempts to auto-fetch the rate from the exchange-rate service; if none is found (or you disagree with it), enter the rate manually. The dialog displays the computed shop-currency equivalent in real time:

Exchange Rate (1 SHOP-CURRENCY = X PAYMENT-CURRENCY)

Each payment row stores both the original amount (in its own currency) and the converted amount (in the shop currency), so you can reconcile against either side of the books. When every payment shares one currency the Payments card totals in that currency (broken out as Net / Tax / Tariff / Total when any payment carries tax or tariff); as soon as the payments span more than one currency it switches to a single total converted into your shop’s currency.