Once you buy fuel, parts, or subcontract labor in more than one currency, your books need a disciplined way to record foreign activity while still producing a coherent report in your functional currency — the currency you use for pricing, payroll (operationally), and management decisions. Multicurrency is not “a toggle.” It is a set of conventions: dated rates, how entries convert, and what you do at period-end when exchange rates move.
Rates and journal legs
A usable rule is to maintain rates as “units of functional currency per one unit of foreign currency.” Journal lines may carry foreign amounts; the system converts to functional with transparent rounding. Rounding noise should land in a dedicated FX plug (gain/loss) rather than silently distorting operational accounts.
Translation vs transaction FX
Transaction FX arises at booking time: you post a bill or receipt in CAD while your functional currency is USD. Translation is reporting: restating balances at a chosen rate for presentation (for example, a trial balance “as-if” shown to a lender in USD with an as-of spot). Those are related ideas with different purposes; mixing them without documenting your convention creates surprise variances.
Revaluation: what software can responsibility cover
Revaluation adjusts carrying values when rates move — typically for monetary balances and foreign-denominated assets you track rigorously. Liability-side and consolidated-policy complexity grows quickly; operator-grade tools should be explicit about scope rather than pretend statutory completeness. Privbooks documents its product boundaries in the README; the point for readers is: know what your tool assumes, and have counsel on what your entity must file.
Not tax filings, not payroll compliance
FX in software is bookkeeping mechanics. It does not replace VAT/GST returns, 1099 programs, or payroll withholding rules. Privbooks focuses on GL accuracy and transparent calculations — not government submission workflows.