Choose your functional currency as the accounting anchor, then set invoice currency by project goal. For presentation currency for financial reports, keep reporting display choices separate from what the client pays, and document contract currency, payment term, conversion timing, and fee ownership before work begins. Use client currency when approval friction is the main concern and your margin buffer can absorb movement; keep your base currency when predictability and simpler reconciliation matter more.
Use one currency to anchor your books, and treat client-facing currency as a separate commercial choice. Your functional currency is your accounting base. The currency you show on proposals, contracts, and invoices shapes communication, approvals, and payment. Keeping those roles separate reduces confusion in reporting, reconciliation, and margin tracking.
Start with your accounting base, not client preference. Under IAS 21, your functional currency is the currency of the primary economic environment in which you operate, and any other currency is foreign currency to your business.
Treat that as a business reality, not something you change from project to project. For U.S. tax returns, the IRS states that federal income tax determinations are made in your functional currency, and amounts on the return are reported in U.S. dollars. If your functional currency is not U.S. dollars, year-end results are translated into U.S. dollars for return reporting.
Before you send international invoices, make sure your ledger and reporting process are built around one clear base currency. If that base is unclear, fix that first.
If you need help pinning that down, read A Guide to Functional Currency for Your Business.
Keep reporting terms and invoicing choices distinct. Under IAS 21, presentation currency for financial reports means the currency used to present financial statements, and financial statements may be presented in any currency or currencies. Your invoice currency is a client-facing term you set in commercial documents.
| Item | What it controls | Who decides it | Where it appears | Risk if you blur it |
|---|---|---|---|---|
| Functional currency | Accounting base and foreign-currency classification | Business economic environment | Ledger, core accounting records | Inconsistent records and harder reconciliation |
| Presentation currency for financial statements | Display currency of formal financial statements | Reporting decision makers, under applicable standards | Financial statements | Mistaking display format for accounting substance |
| Invoice currency | Currency the client sees and pays | You and the client via contract or invoice terms | Proposals, contracts, invoices, payment requests | Taking FX exposure or adding payment friction unintentionally |
The simple rule: invoice currency is a deal choice, not your accounting identity.
Once the client-facing currency differs from your functional currency, translation becomes operational work you need to control. IAS 21 explicitly addresses translating financial statements into a different presentation currency and identifies exchange-rate selection as a core issue.
In practice, translation is the bridge between what the client pays and what your books require. If you bill in a non-functional currency, use a consistent conversion method and rate source in your records. For bookkeeping mechanics, see How to Manage Bookkeeping for Your Freelance Business.
Start here. Treat invoice currency as a risk-management choice, not an autopilot default. Exact risk ownership can vary by contract terms, payment flow, and conversion settings. Decide what you control at invoice issue, payment receipt, and conversion, then document that choice so it is repeatable.
Before you send anything, confirm these points:
This is your control map. If payout settings auto-convert, document exactly where that happens so you can review exposure consistently.
Use this table as a decision aid, not a legal rule. It frames the governance and risk tradeoffs; it does not state a universal rule for invoice-currency mechanics.
| Path | Risk owner (practical view) | Cashflow predictability | Client friction | Margin exposure | Usually appropriate when |
|---|---|---|---|---|---|
| Invoice in your base currency | Case-specific; contract terms, payment rail behavior, and account settings determine where risk sits | Varies; may feel more stable in your planning currency | Can be higher for some cross-border clients | Depends on rates, fees, and conversion path | Internal predictability is the priority and terms are clearly documented |
| Invoice in the client's currency | Case-specific; settlement setup can move more FX-management steps into your workflow | Varies; may stay less certain in your planning currency until conversion is complete | Can be lower for the client | Depends on rates, fees, and conversion path | Client convenience is strategic and you can absorb potential variance |
Run a quick downside check before approval. A simple scenario is often enough to show whether the commercial convenience is worth the exposure.
| Input | Fill this in |
|---|---|
| Invoice amount | [Enter amount and invoice currency] |
| Payment term | [Net 7 / Net 15 / Net 30 / milestone schedule] |
| Rate at invoice | [Add current rate assumption after verification] |
| Rate at settlement | [Add later rate once paid, or model a downside case] |
| Net gain/loss in your base currency | [Expected usable cash minus planned base-currency amount] |
Use this as a screening tool. If a plausible move would materially compress your buffer, treat that as a pricing or terms issue before you invoice.
Before you approve an exception, run a quick risk screen:
| Check | Question |
|---|---|
| Payment terms | Is the exposure window acceptable for this project? |
| Pair volatility | Has the pair moved enough recently to matter over your term? |
| Margin buffer | Can this project absorb a reasonable adverse move? |
| Conversion fees | Is fee responsibility explicitly assigned? |
| Contract protection | Do you need a currency clause or re-pricing trigger for this scope? |
Use judgment. A checklist supports your decision; it does not replace it.
Consistency matters more than clever one-off decisions. Set one default policy, then allow exceptions only when the commercial case is clear and the screen above passes.
For every exception, log the decision in the deal file before invoicing: contract currency, invoice currency, receiving path, payout setting, fee allocation, and the rate evidence you will retain after settlement. That record keeps bookkeeping and reporting aligned with what you actually chose.
You might also find this useful: A guide to currency options for 'hedging' against forex risk.
Before you commit to a client currency, run your likely payment paths through the Payment Fee Comparison. It helps you compare which option is more likely to protect your margin after conversion and transfer costs.
Once you know how much risk you are willing to carry, choose invoice currency as a client-workflow decision. If local-currency invoicing makes approval and payment easier for the client's finance process, it can improve payment speed. Keep it inside the risk limits you set in Pillar 1.
Start with the client's AP process, because matching rules can create delays. Client AP controls commonly match invoice, PO, and receipt. Unresolved discrepancies can leave an invoice parked until someone clears the mismatch.
| Factor | What to confirm |
|---|---|
| PO or approved budget currency | Is the PO or approved budget already in the same currency you plan to invoice? |
| Structured e-invoicing | Does the client use structured e-invoicing, including Peppol? |
| Bank and conversion costs | Who is responsible for bank and conversion costs? |
| Receiving path | Can your receiving path hold that currency, or does it auto-convert on receipt? |
Confirm these points before you localize.
If the client uses Peppol BIS Billing, invoice currency is a required field and the invoice uses one invoice currency, with the VAT accounting currency exception. Keep the structure clean instead of mixing currencies across line items and totals.
Your functional currency remains your internal anchor, even when you present or invoice in another currency. The practical question is when client-currency invoicing helps enough to justify the added exposure.
| Engagement type | Recommended currency posture | Why it helps the relationship |
|---|---|---|
| New client, one-off scope | Keep your functional-currency default | Contains risk while payment behavior and settlement mechanics are still unproven |
| Repeat client, short terms, healthy buffer | Consider client-currency invoicing | Can simplify AP handling when procurement records already align to that currency |
| Strategic or long-term account | Localize when PO, budget, and payment rail are all confirmed in that currency | Aligns with how the client buys and processes invoices |
| Thin-margin work or long terms | Keep default unless pricing or terms absorb FX movement | Protects margin where adverse moves matter more |
| Strict PO-matching / structured intake client | Prefer the currency already used in procurement documents | Reduces discrepancy risk, including exchange-rate tolerance holds |
Use a simple boundary. Localize only when the relationship value is clear, client documents already align to that currency, and your downside is acceptable over the payment window.
The tone matters here. State your default and your exception path in proposals and invoice terms so it reads like operating discipline, not pressure.
Example: "Standard invoicing currency: [your functional currency]. For ongoing engagements, we can invoice in [client currency] when PO currency, payment method, and settlement path are confirmed in advance."
This keeps you flexible while making the approval conditions explicit.
Tie exceptions to verifiable conditions, not optimism. Apply the relationship-versus-transaction test using checks you can actually verify.
Localize only when all are confirmed:
If any check is missing, keep your default currency. That matters most for new buyers and longer settlement windows, where exchange-rate differences and AP tolerances can create more room for holds or delays.
For a step-by-step walkthrough, see A Guide to Financial Ratios for Business Health.
If you invoice in a different currency from your functional currency, keep the process straightforward and consistent. Use one written policy and apply it the same way from invoice issue to settlement. Day-to-day reliability comes from consistent records and evidence.
A practical control is to keep the source record in the invoice currency and keep converted values clearly separate. Keep key fields together, such as invoice date, currency code, amount, client, and file location.
Use explicit unit tagging in your records so values are not mixed across units. In reporting data, currency and non-currency units are separated (iso4217:USD, xbrli:shares, xbrli:pure). Think of that as a reminder not to mix units in your own process.
| Setup | Operational effort | Error risk | Fit by client mix |
|---|---|---|---|
| Single-currency default | Varies by process design | Varies by controls | Mostly one-currency work, occasional foreign invoices |
| Selective multi-currency | Varies by process design | Varies by controls | A smaller set of repeat cross-border clients |
| Broad multi-currency | Varies by process design | Varies by controls | Frequent multi-currency billing across many clients |
Posting without settlement evidence is often where multi-currency bookkeeping gets messy. Before you post, capture these items from the actual settlement record:
| Field | What to capture |
|---|---|
| Settlement date | From the actual settlement record |
| Conversion rate | Rate used for conversion under your internal policy |
| Converted amount | Converted amount in functional currency |
| Fee treatment | Fee treatment under your internal policy |
| Evidence location | Bank statement, payout record, or processor screen |
If dates differ, use a consistent rule and document it.
Keep entries tied to reporting periods instead of treating them like undated balances. Period-bounded records, for example 2025-01-01 to 2025-12-31 and 2024-01-01 to 2024-12-31, are a useful model for a clean close and cleaner reporting.
Use and adapt this template to document the policy:
[functional currency][your approved triggers][define internally][set an internal cadence to clear unmatched items, partial settlements, and fee differences before tax and presentation-currency reporting]We covered this in detail in How to Create a Financial Forecast for a Funding Round.
Choose invoice currency deliberately for each client, not by habit. Set the primary goal first, then align currency and payment terms to that goal.
Name the one outcome that matters most on this deal, for example: margin protection, lower client friction, or simpler operations. Then run the 3-Pillar sequence in order: goal -> pillar -> invoice currency and payment terms.
Use this as a decision worksheet, not a fixed rulebook.
| Deal context | Primary goal to prioritize | FX risk owner (must be set in your terms) | Client friction | Bookkeeping load | Recommended starting posture |
|---|---|---|---|---|---|
| Current deal (new or ongoing) | Choose one goal and document it | Define explicitly in contract and invoice workflow | Assess based on the actual payment flow for this client | Assess based on your close and reconciliation process | Start with the simplest setup you can execute and reconcile, then revisit after closed-month results |
Before work starts, lock the rules in writing: invoice currency, any agreed conversion timing, and who covers fees. Put the same rules in your contract or SOW and your invoice setup so legal terms and operational execution match.
Do not judge the choice too early. Review outcomes only after month-end close is complete. Confirm bank and credit card reconciliations are done, compare actuals to plan, and check trends across the previous three to six months instead of reacting to one month.
Run this as an operating checklist: review at onboarding, after scope changes, and before renewals. If an edge case blurs invoicing choices with reporting choices, revisit A Guide to Functional Currency for Your Business.
If you want a deeper dive, read Hiring Your First Subcontractor: Legal and Financial Steps.
If you want one workflow for invoicing, receiving funds, and payouts with traceable records where supported, review Gruv for Freelancers.
Use your functional currency when predictability is the priority. Use the client’s currency when reducing client friction matters more and you can absorb exchange-rate movement. Put that choice in the contract or statement of work, and lock one invoice currency per project before the first invoice.
Invoice currency changes your conversion workflow, while tax treatment depends on your filing jurisdiction. For U.S. returns, amounts must be reported in U.S. dollars, using the exchange rate prevailing when you receive, pay, or accrue the item.
Your functional currency is the currency of the primary economic environment where you operate. Under IAS 21, your presentation currency for financial statements can be different from that functional currency. If you want the base definition first, read A Guide to Functional Currency for Your Business.
For cleaner payment execution, many teams use one settlement currency and one amount due per invoice. Make sure the invoice header, currency code, and payment instructions match exactly. If you need flexibility, set the currency rule in the contract and keep each invoice single-currency.
The party that converts the funds usually bears the direct conversion charge. If the client pays in your home currency, the client usually converts. If you accept client currency and convert later, you usually absorb that cost. Where EU transparency rules apply, providers must show conversion charges clearly for certain card payments and online credit transfers, so keep that fee evidence with settlement records.
Treat ECB reference rates as context, not as your transaction benchmark. The ECB states those rates are informational and discourages using them for transaction purposes. They are typically updated around 16:00 CET on working days, so record the actual rate source and conversion timing used in your books.
Choose tools based on controls and auditability, not branding. Prioritize multi-currency receiving, control over when conversion happens, reconciliation exports with settlement date, rate, fees, and net proceeds, and clear fee disclosure before transfer. If a setup forces auto-conversion or hides payout detail, your close process gets harder and errors are harder to trace.
Based in Berlin, Maria helps non-EU freelancers navigate the complexities of the European market. She's an expert on VAT, EU-specific invoicing requirements, and business registration across different EU countries.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Educational content only. Not legal, tax, or financial advice.
**Start with a risk-control sequence, not an ad hoc handoff.** As the Contractor, your goal is simple: deliver cleanly, control scope, and release payment only when the work and file are complete.
Control over cash starts with records you trust. When entries are current, categorized, and easy to trace, you spot risk earlier and make calmer decisions about follow-up, spending, and month close.
Your functional currency for business is the currency of your business's primary economic environment. It is the base currency you use to measure performance. Use the wrong base, and results can look weaker or stronger because of translation noise rather than real operating change.