Getting paid in three different apps is a nice problem to have, right up until you try to work out what you earned. One screen shows sales, another shows a payout, and your bank shows the same money arriving again. Add a second currency and an unpaid invoice, and a simple total becomes surprisingly easy to get wrong.
Start with a record of money received. Give each payment a source, a received date, an amount, and a currency. Keep expected payments on a separate follow-up list. You can use a spreadsheet or an income tracker; these rules matter more than the tool.
Name who paid you, not just the payment app
Your income source is the client, employer, shop, or platform behind the work. The payment method is how the money reaches you. Keeping them separate lets you answer a useful question later: which work is bringing in income?
If three clients pay through Wise, labeling every payment “Wise” tells you where the money traveled but hides the three client relationships. Record the client names and put the payment method in a note if you need it.
| What happened | Source name | Useful note |
|---|---|---|
| A studio paid your project deposit | North Studio | Website refresh — deposit — INV-028 |
| Your employer paid your salary | Your employer’s name | November salary |
| A marketplace sent a combined shop payout | Your shop or marketplace name | Payout reference and sales period |
Choose names you'll recognize in six months. “North,” “North Studio,” and “NS Ltd.” may all mean the same client to you today; they look like three sources in a report. Reuse the same saved source when adding the next payment.
For a marketplace that combines many sales into one payout, decide whether your record follows individual sales or combined payouts. Keep the detailed sales statement separately if you use payouts. Don't add both as fresh income.
Record received money separately from expected payments
A client accepting a quote is encouraging. A sent invoice is progress. Neither is the same as a payment arriving. For this everyday received-money system, add income when it reaches the account or balance where you receive payments, using the date it arrived.
Keep expected amounts in your invoicing tool or a separate list with the client, reference, due date, and next follow-up. Payday records received income; it doesn't manage pending invoices.
If a project has a deposit and a final installment, create an entry for each amount as it arrives. Connect them with a short note. Recording the full project value at the start and then the installments later would count the same work twice.
A payment may also be pending or held inside a platform. Check the platform's status and statement instead of treating every sales notification as an available payout. Use a consistent received-date rule, and retain the source documents for any formal reporting you need to do.
Choose one fee method and exclude your own transfers
Here's a fictional sale in US dollars: a platform reports $500, deducts a $25 fee, and pays out $475. You have two useful ways to explain it:
- Track the received amount: record $475 of income, with “$500 sale less $25 fee” in the note.
- Track gross sales and fees: record $500 of income and $25 of expense.
Both leave $475, but their income totals mean different things. Pick the approach that fits your records and apply it consistently. If you record the $475 net payout, don't subtract that same $25 fee again. These are tracking examples, not instructions for tax reporting.
When you move the $475 from the receiving account to your bank, that's your money changing location. It isn't a second sale. The bank notification is satisfying; it still doesn't get a second income entry.
Use actual transaction records to check the journey. Wise's statement guide explains how to export records for selected currencies and periods. It also distinguishes currency-account statements from its broader transfer list, so choose the record that covers the activity you're reviewing.
Keep original currencies before calculating a total
Save the original amount and currency even if you think in your home currency. A USD 200 payment and a EUR 200 payment are not simply “400.” Keeping their original values lets you check either one against its payment confirmation later.
For an overview, choose one home currency and use a consistent conversion basis. Label the result as approximate if it uses reference rates. The European Central Bank says its reference rates are for information, not transaction pricing. The amount a provider actually converts can differ because of its rate, fees, and timing.
Add a source country when you know it, but don't infer it from currency alone. A client in Japan can agree to pay in US dollars. If you later exchange the payment, keep the conversion receipt too; an estimated home-currency total and an actual bank deposit answer different questions.
Work through one week without counting anything twice
Imagine you have a salary, a freelance client, and a small template shop. This example uses the received-amount method for the shop payout. All amounts are invented.
| Event | Income entry | Reason |
|---|---|---|
| Salary reaches your bank | PHP 50,000 | Received payment |
| North Studio pays a deposit | USD 300 | Received installment |
| Shop pays $475 after a $25 fee | USD 475 | Net payout; fee already deducted |
| You move that payout to your bank | No new income | Transfer between your accounts |
| You send a EUR 200 invoice | No received income yet | Put it on the follow-up list |
Your received amounts are PHP 50,000 and USD 775. For a deliberately simplified comparison, assume USD 1 = PHP 56. That is a made-up rate for this example, not a current quote.
Estimated income in PHP = 50,000 + (775 × 56) = PHP 93,400.
If you separately paid PHP 1,120 for a project asset, that leaves PHP 92,280 after the expense in this example. Don't subtract the platform's $25 again: the $475 payout already reflects it. Taxes, other obligations, and costs you haven't entered are outside this calculation.
Make the system easy to keep using
Use a short note format you can repeat: project or sale period / installment / reference. You rarely need a paragraph. The goal is enough context to recognize the payment without reopening five apps.
Once a week, match new entries to statements and confirmations. Check for duplicate imports, transfers counted as income, inconsistent names, and fees deducted twice. Update the separate expected-payment list when something arrives.
Before importing a CSV, compare its date range with what's already recorded. Try a small batch, inspect the amounts and currencies, and check the total. Keep an export or backup of your records using your normal backup process before a larger cleanup.
Once the records are clear, look for patterns worth acting on: repeat clients, a growing shop, or a source that depends on one large payment. The weekly side-income review helps you turn that information into a practical next step.
