Docs · Memo & Consignment

Returning a memo piece — or buying it

The two ways an active memo or consignment-in row exits. Returning a piece is shipped end to end. Buying a piece to convert it into owned inventory is being built; the manual workaround in the meantime is documented inline.

Some functionality on this page is partial — see the honest disclosure section below for what's shipped today and what's in build.

Quick reference

Return — the piece goes back to the supplier (or the customer returns it from memo-out). Click the row, then Return in the slide-over panel. Status flips to returned; today's date is stamped as the returned date.
Mark as Sold — the customer kept the piece (memo-out) or you sold the piece to a walk-in (consignment-in). Status flips to sold; sold date stamped. If the row is linked to an inventory piece, the linked inventory row decrements through stock_movements.
Convert to Owned Stock — turning a consignment-in piece into a piece you've bought, so it joins owned inventory. The button exists in the slide-over panel but is disabled today. The honest disclosure below covers what to do in the meantime.
Both status changes require the edit_inventory permission. Owners and managers have it by default.
Every transition writes to the activity log and the audit log — operator, old state, new state, timestamp. The record survives the row.

Returning a piece

1. Find the row

Open /memo and pick the tab — Memo Out for a piece a customer is returning, Consignment In for a piece you're sending back to a supplier. Filter by Active status, or use the search bar to find the row by reference number or item name.

If the piece is overdue, it'll surface near the top of the active list with a red clock and red date — useful when you're working through the supplier-return backlog at month-close.

2. Open the row, click Return

Click the row to open the slide-over panel from the right. The panel shows the full row detail and, at the bottom, two action buttons side by side: Return and Mark as Sold.

Click Return. The action runs immediately — there's no confirmation modal between the click and the database write. The status flips to returned, returned_date is stamped to today (in the tenant's time zone), and the slide-over closes.

Screenshot pending

The slide-over panel for an active consignment-in row with the Return and Mark as Sold buttons at the bottom of the panel, side by side.

3. The row now shows as returned

Back on the list, the row carries a returned status badge (neutral grey) and the returned date in place of the due-back date. The row drops out of the Active filter view — use the Returned status chip or All filter to see it again. Active Value tile drops by the row's retail value; Overdue Items count drops by 1 if the row was overdue before the return.

The activity log entry — “memo status returned, operator [name], reference CON-####” — is the audit trail your accountant or the supplier rep can reference if anyone asks when the piece left.

Marking a piece sold

1. When to mark sold

Use Mark as Sold when:

(memo-out) a customer took a piece home on memo and decided to keep it — the sale will be rung up through the regular POS for the price negotiated;
(consignment-in) a walk-in bought a consignment piece off the floor and the sale ran through POS.

In both cases, the POS sale and the memo-status flip are separate actions today. The POS sale records the revenue side; the memo flip records the disposition of the memo arrangement (which is what the supplier or the audit cares about). Don't rely on POS to flip the memo row — the link is one direction (memo row → inventory row, when present), not the reverse.

2. Click Mark as Sold

In the slide-over panel, click Mark as Sold. The action runs immediately. The row's status flips to sold, sold_date is stamped to today.

If the memo row has an inventory_id link to an owned-inventory row, the action also writes a sale movement to stock_movements with quantity_change = -1 against that inventory row. The database trigger decrements the inventory quantity. The note on the movement is “Memo [id] sold” — searchable in the inventory history view.

Without an inventory link, no stock movement runs — the row flips to sold and the audit log captures it; that's the full record.

3. The row reads as sold

The row carries a green sold status badge and the sold date. It feeds the Reports panel's Commission Earned tile, which sums retail_value × commission_rate ÷ 100 across all sold rows. At month-end, that's the number you remit back to the consignment supplier for their share of sales.

The remittance itself — cutting the cheque, posting the invoice into Xero, sending the supplier a payment notification — happens outside this surface. The amount owed is captured here; the cash side runs through your accounting flow.

Honest disclosure — the “buy this piece” conversion

There's a third exit from active state — converting a consignment-in piece into owned inventory because you've decided to buy it from the supplier rather than send it back. This is the most common outcome on a piece that's sat in the case past its window and that you no longer want to be on a return clock for.

The slide-over panel has a Convert to Owned Stock button at the bottom, separate from Return and Mark as Sold. The button is in place, with the label “(coming soon)” next to it. It's disabled today — clicking it does nothing, hovering surfaces the tooltip “Conversion to owned stock in a future release.”

The conversion needs to do three things atomically: flip the memo row to a terminal “converted” state, create (or update) an inventory row in your owned-stock table with the agreed wholesale price as cost and the existing retail value as price, and write the corresponding stock_movements entry with movement type “Memo conversion”. The all-or-nothing shape — either all three succeed or none do — is what keeps the memo ledger and the owned-inventory ledger from drifting. The three-write transaction with rollback handling and audit coverage is what we're building.

The interim workaround is two manual steps. First, on the memo row, click Mark as Sold — this flips the memo to a terminal state and writes the sold-date stamp. Second, go to /inventory/new and create an owned-inventory row for the piece manually: same item name, the agreed wholesale price as the cost field, the existing retail value as the retail price, and the supplier set on the supplier link. Add a note in the inventory row's description that this was converted from memo reference CON-#### — so the audit trail across the two ledgers can be reconstructed.

The cost of the workaround: the cross-ledger link is implicit (carried in the description note) rather than structural, the two writes aren't atomic (a power failure between the two steps leaves you with a sold-memo and no inventory row), and the financial cleanliness — owed cost to the supplier, recorded purchase, inventory valuation increment — has to be handled by your accountant rather than the system. None of those costs are dangerous in practice (the workaround works), but they surface as work the system should be doing.

Related product context lives on the problem page at The memo that vanished — the customer-side framing of the same window-closes-while-piece-is-still-in-the-case failure mode this page is the operational counterpart to. Talk to us if these are load-bearing for your store.

Common questions

I clicked Return by accident. How do I undo it?

There's no in-product undo for memo status changes today — the transition runs immediately and there's no confirmation modal between the click and the database write. If you flipped a row to returned by mistake and the piece is actually still in the case, the row's status can be updated directly via the row-edit API or by support. Contact us with the reference number and we'll flip it back; the audit log will carry both the accidental change and the correction, so the trail stays honest.

Is there a confirmation step before Return or Mark as Sold fires?

No. The two buttons in the slide-over are one-click. The design reasoning is that these are routine staff actions — a return or a sale is the expected outcome on every active row eventually, and putting a confirmation modal between every click would add friction without preventing the actual mistake (which is clicking the wrong button on the wrong row, not clicking the right button at the wrong moment).

The mitigation is that every transition writes to the audit log, so a mis-click is recoverable through the contact path above. A confirmation prompt with the row reference and the intended new state is on the backlog — useful for stores where memo volume is low and an accidental click is more disruptive than the friction it avoids.

A customer brought back a memo-out piece they'd already been billed for. What do I do?

The memo flow doesn't bill — billing happens through POS, separate from the memo row's status. If the customer was billed, that's a POS sale that ran earlier; the memo row should've been marked sold at that point. Today the row is either:

(a) still in active state — meaning the POS sale ran but the memo wasn't flipped to sold. Mark the memo sold now to true up the ledger, then process the customer's physical return as a regular POS refund. See /docs/sales-and-pos/refunds.

(b) already in sold state — meaning the previous staffer flipped it correctly. The customer's physical return is a POS refund only; the memo row doesn't change. The refund flow re-adds the inventory row.

A memo piece is overdue. The customer hasn't responded. What state do I move it to?

Two reasonable answers depending on the context. If you still expect resolution — the customer is travelling, the supplier is paperwork-slow, the piece is in the post — leave the row as active and let it sit on the overdue list. Active is the right state for “still expected to resolve.” The red clock and the Reports counter are the surfacing mechanism; they're not asking you to do anything other than notice.

If you've decided the arrangement has lapsed and you're going to manage the cleanup outside the system (writing the piece off, escalating to a collections conversation, accepting the loss), mark it expired. That drops it off the overdue list — because it's no longer expected to resolve through the normal flow — while keeping the row visible for reporting. Expired is distinct from lost: expired means the window closed and the piece is somewhere the system doesn't track anymore; lost is for damage, theft, or definitive disappearance.

The piece on memo got sold by mistake to a walk-in before I'd agreed the purchase with the supplier.

This is the consignment-in equivalent of selling a piece that wasn't yours to sell — uncommon, but it happens. The sequence to recover: mark the memo row sold (it is sold; you can't undo the customer transaction). Pay the supplier their wholesale value plus their commission from your end — the row already captures both numbers. Communicate with the supplier rep that the piece sold before the formal purchase, and confirm they're happy with the post-fact arrangement (they usually are; a sale is a good outcome from their side too).

The Reports panel's Commission Earned tile will reflect the commission on the sale automatically. The remittance is the conversation; the system has captured the facts.

Troubleshooting

“You don't have permission to update memo items”

Symptom: clicking Return or Mark as Sold surfaces a permission-denied error. Cause: the status transition is gated on the edit_inventory permission — the same gate as stock adjustments, transfers, and batch receive. Your role doesn't have it. Fix: ask an owner or manager to make the transition for you, or to grant the permission to your role from /settings/team. The gate is intentional — memo transitions move money-equivalent records, so the access policy is the same as the rest of inventory mutation.

The memo row flipped to sold but POS is still showing the inventory piece as available

Symptom: you marked the memo sold, but an associate tried to ring up the same piece through POS and the inventory shows quantity 1. Cause:the memo row didn't have an inventory_id link to an owned-inventory row, so the sale-decrement movement didn't fire. The memo flipped sold; the inventory decrement is the half that was conditional on the link. Fix: if you have an owned-inventory row for the piece, run an Adjust Stock on it with reason Sold and a note referencing the memo number. That keeps the inventory count honest. Going forward, the linkage from memo row to inventory row at intake is the path that makes the decrement automatic — today the link has to exist for the trigger to fire.

I clicked Convert to Owned Stock and nothing happened

Symptom:the button looks pressable but the click doesn't do anything. Cause:the button is intentionally disabled — the conversion flow is being built. The tooltip on hover reads “Conversion to owned stock in a future release.” Fix: use the manual two-step workaround documented in the honest disclosure section above — mark the memo row sold, then create the inventory row manually from /inventory/new with a description note linking back to the memo reference. The atomic conversion is the next significant piece of work on this section. Talk to us if this is load-bearing for your store.

A returned row I want to re-open back to active

Symptom: a memo row got marked returned, but the customer / supplier actually changed their mind and wants the piece back on memo. Cause:returned is a terminal state in the UI — there's no “reopen to active” button. Fix:create a new memo row for the same piece with a note linking the earlier returned row. The new row gets a new reference number; the audit trail across the two captures the “came back, went out again” sequence honestly. If you'd rather edit the existing row directly, contact us — we can flip the status back, but the audit log will show both transitions, which is the right outcome.

Back to Memo & Consignment