Written by DROPS.ST.
For a cannabis shop, reconcile crypto payments by linking the business order, its payment request and the evidence of receipt. Compare their amount and currency bases before closing a difference. Similar totals or matching calendar dates are not enough.
DROPS gives the review a practical starting point: configured Bitcoin and Monero checkout carries an order reference and payment status alongside the customer-linked order. The website and connected Telegram shop share the order system, so staff can work from the same shop reference. Explore DROPS features.
Define which records you are matching
An order records the selected goods. A payment request describes what the customer is asked to pay. A payment transaction records movement associated with that request. A later merchant receipt or conversion may be a separate event.
The SHKeeper documentation distinguishes the store's external reference, invoice information, balances and transactions. That is a useful reason to preserve the relationships rather than keeping one unexplained “paid” total. SHKeeper invoice documentation.
First define the period and records under review. Keep crypto and e-transfer or other methods identifiable; do not apply one method's evidence rules to all receipts.
Use a reconciliation worksheet with explicit references
This original worksheet belongs in your approved business-record process. Confirm actual export formats and accounting connections separately.
| Record element | Keep | Check |
|---|---|---|
| Shop order | Stable order reference and selected items | Correct business transaction? |
| Payment request | Request reference and chosen method/asset | Linked to that order? |
| Payment evidence | Relevant transaction or payment-record references | Credited to the intended request? |
| Amount basis | Amount, currency/asset and source | Comparable values? |
| Charges | Separately identified fees and their evidence | Gross, charge and net distinguished? |
| Merchant receipt | Separate receipt/conversion reference where applicable | Actually received, pending or unverified? |
| External reference | Relevant PO, POS or channel record | Same commercial event? |
| Timing and difference | Event times, time zones and unresolved question | Correct period and next owner? |
Use only the necessary references and restrict access appropriately. Start support checks with the order and payment references, then justify any additional evidence. Never request seed phrases, private keys or wallet passwords.
Match references before comparing totals
Follow the recorded relationship from the order to its payment request and supporting receipt. Preserve the original references rather than replacing them with a convenient spreadsheet row number.
If an order has multiple payment requests or transactions, preserve each relationship rather than assuming a one-to-one match.
For a wholesale order, a buyer's purchase-order number is an additional business reference. It does not replace the shop order or prove payment. Likewise, an external POS entry needs its own checked relationship; a similar amount does not establish an integration or a match.
Inspect duplicate references before counting sales. A website order and a Telegram notification about that order are not two transactions. Conversely, two genuinely distinct orders can have the same total. Keep unresolved matches visible instead of choosing whichever row makes the total balance.
Keep amount and timing bases visible
An order price, received crypto amount and later bank receipt may use different currencies or valuation events. Record what each value represents. Separate processing, network and conversion charges where they actually apply and are supported by evidence.
For Canadian GST/HST registrants accepting crypto for taxable property or services, CRA requires transaction-time fair-market valuation and supporting calculation records. Your accountant should establish the applicable treatment and required evidence. CRA: crypto-asset GST/HST guidance.
Outside Canada, have a qualified local adviser establish the applicable evidence and reporting treatment.
Keep order creation, payment recognition and any later receipt timestamps distinct, including their time zones. Around midnight or month-end, a calendar-date mismatch may reflect different events. Preserve those facts for the authorized reporting decision rather than moving dates to force agreement.
Hypothetical example: two channel rows, one order
A review sheet contains a website entry and a Telegram entry with the same fictional order reference O-42. Both point to payment record P-21.
The reviewer checks the source relationships and finds one order represented twice. They count that order once and retain the second entry as channel context. A separate POS reference remains unmatched, so it stays open with an owner instead of being assumed equivalent because its total looks similar.
This example demonstrates the matching decision, not a native deduplication or POS integration feature.
Close differences with evidence and an owner
Record matched, unresolved or deliberately excluded outcomes with their basis. Short payments, excess amounts and expired requests need the payment exception review; correcting a spreadsheet does not resolve the shop case.
Keep multi-invoice allocations, supplier credits and refund decisions with their authorized financial process. Do not let one reused receipt silently clear unrelated obligations.
DROPS is a strong fit when you want the customer journey and order context together for this review. Use the payment-flow comparison to distinguish acceptance from merchant receipt.
See DROPS and explore the demos. Bring a fictional order/payment pair and an unmatched record. Inspect the available references, then agree your supported export, reconciliation owner and remaining accounting evidence.