Forty Dollars in Two-Dollar Coins
Canada's Currency Act says that a tender of payment in one-dollar coins is legal tender for no more than twenty-five dollars. In two-dollar coins, forty. In pennies, twenty-five cents. Those are not amounts a system can check, because to check them you would have to know how many pieces of each denomination were handed over — and every point-of-sale system on earth, ours included, records a payment as a single number.
A tender is a set of pieces
Legal tender is a narrow idea. It answers the question of what a creditor must accept in satisfaction of a debt, not what a shop is allowed to agree to take — a retailer who is happy to count out a jar of coins is free to. But the Act is specific about the outer edge of the obligation, and it expresses that edge in denominations rather than in money.
Section 8(2), as five limits
The last row is the one that reads oddly until you notice it is not an amount rule at all. For a coin of a denomination greater than ten dollars, a tender may consist of not more than one coin, and is legal tender for no more than the value of that single coin. A count, not a total.
And then section 8(3) does something that ought to interest anybody who models transactions. Where more than one amount is payable by one person to another on the same day, under one obligation or several, the total is deemed to be a single amount due that day — for the purposes of the two limit provisions above. So the limits do not attach to a transaction. They attach to a <em>relationship over a day</em>, which is a shape most systems have no row for.
The same-day aggregation needs a customer, and at a till the customer is optional
To apply section 8(3) you have to be able to say "these are all the amounts payable by this person to us today". Our till sale carries a customer, and the column is nullable — which is right, because most counter sales are anonymous and forcing a customer onto a bread-and-milk transaction would be a worse product. The consequence is that a rule keyed on a person, over a day, is answerable exactly when somebody attached the customer, and unanswerable otherwise. That is not a defect to fix so much as a shape worth knowing: a statutory rule about a relationship cannot be enforced by a system whose unit is a transaction.
What our till actually records when somebody pays
A payment against a sale in this product is four columns: which sale it belongs to, a method from a fixed list of three, an amount, and a time. That is a complete and correct record of a payment in the sense the accounts care about, and it is missing exactly the dimension the Currency Act legislates in.
What the Act reasons about, against what a payment row holds
| The fact | Recorded per payment | Recorded per session | Reportable |
|---|---|---|---|
| How much was paid | Yes | Yes | Yes |
| By what method — cash, mobile money or card | Yes | Partly — configurable by you | Yes |
| When, to the second | Yes | Yes | Yes |
| In which currency, and in which country | Partly — configurable by you | No | Yes |
| How many pieces, of which denominations | No | No | No |
| What was handed back as change, in pieces | No | No | No |
| Everything one person owed us today | Partly — configurable by you | No | Partly — configurable by you |
Built and maintained Configurable by you, not maintained by us Not built
The fourth row is a partial for a reason worth stating: the currency and the country are snapshotted onto the sale rather than onto the payment, so a payment inherits its currency from the document it settles. That is the right call for a till and it means the payment row itself is denomination-agnostic in two senses at once.
The cash drawer is the same story one level up. A cash session records an opening float, the cash sales total, the drops, the expected cash, the counted cash and the variance — six figures, each of them a total. A cashier counting down a drawer at the end of a shift is holding a set of pieces and typing in a number, and the number is what the system keeps. For reconciliation that is correct and sufficient. For any question about denominations it is a one-way door.
A drawer contains pieces. A record contains an amount. The conversion happens in the cashier's head, once, and nothing afterwards can undo it.
Two other things the Act says about money itself
Section 7(2) is worth quoting because it is a physical test sitting in a financial statute: no coin that is bent, mutilated or defaced, or that has been reduced in weight otherwise than by abrasion through ordinary use, shall pass current. Whether a coin is money is partly a question about its condition, judged by a person at a counter — and the record of that judgement is that the coin was not accepted, which is to say no record at all.
Section 13(1) is the one that touches how we model money generally. Every contract, sale, payment, bill and instrument is to be made in the currency of Canada, unless it is made in the currency of another country, or in a unit of account defined in terms of the currencies of two or more countries. That last clause is a nice reminder that a currency code is not always a country: a unit of account defined across several currencies is expressly contemplated. Our position on mixed currencies is the one we have written about elsewhere — we disclose the composition rather than converting and summing — and this section is a useful check on it, because it treats a foreign-denominated transaction as a legitimate thing rather than as an exception to be normalised away.
A payment as a method, an amount and a moment
Every settlement against a till sale is recorded with its method, its value and its timestamp, against the sale it belongs to.
The currency and the country the sale happened in
Snapshotted onto the sale at the moment it was taken, alongside the counter, the warehouse and the location.
A cash session that reconciles to a variance
Opening float, cash sales, drops, expected, counted and the difference between the last two, with the cashier and the times on both ends.
Currency-aware presentation
A figure renders with the number of decimals its own currency uses, and unlike currencies are disclosed side by side rather than added together.
A denomination breakdown on a cash payment
How many of each piece were handed over, which is the dimension every rule about coins is written in.
A denomination breakdown on a drawer count
A close-down that captures the count per denomination and derives the total, rather than accepting the total and discarding the count.
A day's obligations between one customer and you
The amounts payable by one person on one day as a single figure, which needs the customer attached to each sale to exist at all.
A rounding rule on a cash tender
Change is an exact subtraction today; a market where cash settles to the nearest five cents while card settles exactly would want the rule stated where the figure is produced.
Our take
The Currency Act is a small, clear statute and it legislates in a unit our software does not carry. That is not a compliance problem for a Canadian retailer — nothing here obliges you to record denominations, and legal tender is about what a creditor must accept rather than what a shop may agree to take. It is a modelling observation, and a useful one, because two of the four unbuilt items above are worth having for reasons that have nothing to do with this Act. A drawer count captured per denomination and totalled by the system is a better count than a total typed by a tired person, and it makes a float order a query instead of a guess. A day's obligations for one customer is a figure any business with account customers wants. Neither is large. Neither is on our roadmap today, and both would be small builds if a customer needed them.
What AWRA OpsHub does today
- A payment recorded against the sale it settles, with its method, its amount and its time, and several payments allowed against one sale.
- Three tender types at the till — cash, a mobile-money rail and card — held as a fixed list rather than as free text.
- The currency and the country snapshotted onto every sale, alongside the counter, the warehouse and the location it was taken at.
- A cash session that reconciles, carrying an opening float, cash sales, drops, expected and counted cash, and the variance between the last two, with the cashier and both timestamps.
- Cash drops recorded individually, each with an amount, a note, a time and the person who made it.
- Decimals resolved per currency, so a figure renders with the places its own currency actually uses rather than an assumed two.
- Unlike currencies disclosed rather than summed, with the composition shown instead of a single converted figure.
More we can add to your workspace
- A denomination breakdown on a cash tender, recording how many of each piece changed hands, which is the unit every coinage rule is written in.
- A denomination breakdown on a drawer count, so the system derives the total from the count rather than accepting a total somebody worked out.
- A float composition and a float order, which is what a per-denomination count makes possible the moment you have a week of them.
- A day's obligations for one customer as a single figure, across every sale and invoice, which is the shape a same-day aggregation rule needs.
- A rounding rule attached to a tender type, so a market where cash settles differently from card has the rule stated where the change figure is produced.
- A payment that carries its own currency, rather than inheriting it from the document it settles, for the case where somebody pays in a currency the sale was not priced in.
- A record that a tender was declined, and why, which today is a conversation at a counter and nothing else.
Where we point you to a specialist
- We will not tell you what you must accept. Legal tender is a rule about the discharge of a debt, and whether a particular payment discharges a particular obligation is a question for a lawyer and occasionally for a court. What software can do is record what was taken, in what form, by whom and when — and we would rather build that faithfully than put a rule in a till that turns a judgement into a refusal.
- We will not decide the condition of a coin for you. Section 7(2) makes whether a coin passes current partly a question of whether it is bent, mutilated or defaced, judged by the person holding it. That judgement belongs to a human at a counter, and the useful thing a system can offer is somewhere to record that a tender was declined and why, not a rule that pretends to make the call.
- We hold a position on rounding, and it is that a rounding rule belongs where the figure is produced rather than where it is displayed. Change here is an exact subtraction, and if a market needs cash to settle to a coarser step than card, we would put that rule on the tender type and state it on the receipt rather than let a formatter quietly do it. A figure that was rounded and does not say so is the kind of thing that reconciles perfectly and is wrong.
The second item is the one we would start with, because a drawer count per denomination is a better count than a typed total and it makes the third item — a float composition you can order against — nearly free. The first follows the same shape at the tender rather than the session. The fourth is a report over data we already hold, conditional on the customer being attached to the sale. The fifth and sixth touch how a payment is priced and settled and want scoping properly rather than bolting on. The seventh is small and would sit beside the tender list.
What we can build for Canada on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Canada, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If storing the split, not just the total, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The cheapest first build in this corpus, and then three larger ones
Persist the per-levy breakdown onto the document at the moment of saving. The figures are already computed — our engine works out each levy against its own base and returns them — and today they are discarded, leaving a blended rate and one tax type on the record. In a province levying two taxes that means the total is right and the split, which is the only thing either return needs, has to be re-derived from settings that may since have moved. Storing what is already in hand would make every such invoice decomposable for the rest of its life, and it is a fraction of the size of the capability it unlocks. After that: a tax type on the line, a province on the customer and the sale, and a return assembled from the three.
Banks and payments
EFT files and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents rather than being typed twice.
Certifications and inspections, which is where a Canadian commission usually starts
A trade ticket, a medical or an equipment examination with a date that has to be watched, and a consequence when it passes: an asset that cannot be issued, a crew member who cannot be assigned, a list somebody actually receives. Custom field sets and expiry reporting exist today; making an expiry refuse rather than notify is the small build, and it is the same shape of work as the certificate stop we would do in Guyana. Seasonal resupply planning per location — lead times driven by a window rather than a reorder point — is the other one we would expect to be asked for here.
Payroll and statutory returns
A Canadian payroll engine with CPP and EI contributions, T4 and record-of-employment production and provincial levies computed on live employee records. None of it exists today; labour cost attribution to projects and cost centres does.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions for a till you are going to run cash through
How is a cash payment recorded?
What you will probably hear
As a cash tender with an amount.
How to read it
Which is correct and complete for the accounts. Ask whether a denomination breakdown is possible at all, because if the answer is no it is a schema answer rather than a settings answer, and no amount of configuration will produce a float order later.
Show me a drawer count at end of shift.
What you will probably hear
A field for the counted total and a variance.
How to read it
Ask who does the arithmetic. A system that accepts a total is trusting a tired person's addition at the least reliable moment of the day; a system that accepts counts and totals them catches the addition error and gives you the composition for free.
Is the customer required on a till sale?
What you will probably hear
Optional, so the queue keeps moving.
How to read it
Right answer, and worth knowing the consequence: any rule or report keyed on a person over a period only covers the sales where somebody attached one. Ask what proportion of your sales carry a customer before you promise anybody a per-customer figure.
If cash rounds and card does not, where does the rounding happen?
What you will probably hear
The display handles it.
How to read it
Then the stored figure and the shown figure differ and nothing says so. Ask for the rounded value to be the recorded value, with the rule named on the receipt, because the alternative reconciles perfectly against itself and disagrees with the drawer.
Tell us what your till has to prove
Most questions about cash turn out to be questions about pieces rather than amounts, and they are answerable only if somebody captured the pieces at the one moment they existed. If you want the tender side of this product in more detail, <a href="/blog/three-tenders-and-the-one-that-was-never-real">the three tenders and the one that was never real</a> covers the list itself, and <a href="/blog/five-things-a-price-has-to-be">five things a price has to be</a> covers what a money column can and cannot hold.
Talk to us about your workspace