How do I keep track of money I send home to the Philippines each month?

A monthly padala tracking system keeps seven minimum fields per transfer: date sent, channel and provider, amount sent in the sending currency, amount received in PHP, fee, provider reference number (Western Union's MTCN, or the transaction ID on Wise, Remitly, MoneyGram, and others), and recipient confirmation that the payout landed. Below those seven it is a partial record that will not reconcile when something goes wrong. The format can be a spreadsheet, a printed tracker, or a notes file — the structure is what makes it a system. The page below sets out the columns and explains what each one is for.

Isn't my bank or provider's remittance tracker enough?

Those are single-transaction status lookups. PNB, Chinabank, BankCom, Western Union and Wise each let a sender check one transfer by its reference or tracking number, inside that one provider. A monthly tracking system is sender-side and cross-provider — one continuous record across every channel used. The provider's record also exists for a different reason: under the Anti-Money Laundering Act (RA 9160 §9(b)), covered institutions retain transaction records for five years from the transaction date (amlc.gov.ph; checked 2026-09-04). That five-year retention is the provider's regulatory obligation, not a record built for the sender to reconcile a year of padala across Wise, Remitly and Western Union in one place.

What is the most common mistake in tracking padala?

Not closing the loop. Senders log the send-side details — date, amount, fee, reference number — and never confirm with the recipient that the payout actually landed. The line stays open without the sender noticing, and a missed payout is caught weeks later when the recipient calls about a bill that did not get paid. The closing step is one line: the recipient confirms the named PHP amount was received on the named date, and the line is marked closed. The other frequent slip is logging the send-side amount in the wrong currency in a multi-corridor household — a co-sender in the UAE remitting in AED while the primary sender works in USD, one sheet, two currencies.

Does the exchange rate belong in the log?

It is an optional, retrospective column. Recording the effective USD→PHP (or other corridor) rate at each send lets a sender see corridor movement over months and check posted rates against the World Bank Remittance Prices Worldwide tracker (worldbank.org; checked 2026-08-08), which publishes quarterly corridor-level posted total cost — fee plus FX margin — across providers. This page states no view on timing transfers around expected rate moves. What the rate column makes possible is auditing a month that already happened, not predicting the next one.

What does the annual roll-up of a monthly tracker show?

Three retrospective readings: total remitted in the sending currency across the year, total fees paid — the sender's actual cost of that year's channel choices — and the weighted-average effective FX rate achieved, which can be set against the World Bank US→PH corridor figure for the same period. The annual view also surfaces the payout-method mix — bank deposit, cash pickup, e-wallet — which a sender can read alongside the mode-of-remittance tables the PSA Survey on Overseas Filipinos publishes (psa.gov.ph; checked 2026-05-21). The roll-up is a once-a-year reading, not a target.

A monthly padala tracking system: the fields a log keeps, and the closing step most miss

A single monthly padala carries more than one number. There is the amount debited in the sending currency, the fee, the FX rate the provider applied, the amount paid out in PHP, the channel and provider used, the reference number the recipient needs at payout, and the confirmation that the payout actually landed. Each is a separate piece of data, and each is a separate place a slip can happen. A tracking system is what holds those pieces in one place, month after month.

This page sets out that structure. The format — a spreadsheet, a printed tracker, a notes file — is the reader’s to pick. What makes any of them a system rather than a pile of receipts is the set of columns and the closing step.

The log, as a structure

The system is a table with one row per transfer. These are the columns a monthly padala log carries — the header a reader recreates in a sheet or on a printed page, filled in as each transfer goes out.

The monthly padala log — the column structure (one row per transfer) Blank structure — no figures

Date sent	Channel + provider	Amount sent	Amount received (PHP)	Fee	Reference no.	Confirmed?

Seven columns is the minimum. Below it, the record will not reconcile when something goes wrong. Optional columns add audit value over months without being required for the system to work: effective FX rate, recipient and purpose (bills / tuition / food / savings), a cut-off note, and a free-text notes column for a promo applied or a delay observed.

What each column is for

What goes in each column, and why it is kept Blank structure — no figures

Column	What goes in the cell	Why it is logged
Date sent	The calendar date the transfer was initiated, in the sender's local time	Anchors every other field; pairs with the payday cycle and the recipient's cut-off
Channel + provider	Bank deposit / cash pickup / e-wallet, plus the named provider (Wise, Remitly, Western Union, MoneyGram, GCash payout, and so on)	Lets the annual roll-up show the payout-method mix and the per-provider fee total
Amount sent	The full amount debited from the sender, in the sending currency (USD, CAD, GBP, AED), fee included	The sender-side line that ties to the bank statement
Amount received	The amount the recipient was actually paid out in PHP — confirmed, not estimated	The only number that reconciles the transfer; it closes the loop
Fee	The provider fee on this transfer, kept separate from the FX margin	Comparable across months and providers; rolls up to the annual fees-paid total
Reference no.	The provider-issued identifier — MTCN on Western Union, transaction ID on Wise / Remitly / MoneyGram and others	The recipient needs it at cash pickup; the sender needs it to dispute a missed payout
Confirmed?	A one-line note that the recipient confirmed the named PHP amount arrived on the named date	The closing step; an unconfirmed line is a silent failure waiting to surface

This table carries no figures — it is the structure, not a set of rates. The values a reader fills in are their own.

The column most often skipped

Of the seven, the confirmation column is the one most often left empty and the one whose absence causes the most silent failures. A send-side debit shows up on the sender’s bank statement, the provider posts a “transfer complete” status, and the sender treats the line as closed. The “complete” status means the transfer left the sender. It does not mean the recipient was paid out.

The payout can be delayed, held for a compliance review, or sent to a recipient-name match that did not clear. Closing the line takes one note: the recipient confirms the named PHP amount was received on the named date. With that note, the line is closed. Without it, the line is open even when everything else in the row looks finished.

Why keep your own record when the provider keeps one

The provider’s record is for the provider. Under the Anti-Money Laundering Act (RA 9160 §9(b)), covered institutions — the BSP-supervised banks and remittance and transfer companies most padala runs through — must retain transaction records for five years from the transaction date (amlc.gov.ph; checked 2026-09-04). That obligation sits on the provider, to satisfy regulators. It is not a record built for the sender.

The sender’s own record does work the provider’s record cannot do for the sender:

What a sender-side record does that a provider's does not

It is readable offline

The recipient needs the reference at cash pickup, often from a phone with patchy data, sometimes from a remittance counter with the sender on a slow international call. A number written in the sender's own tracker is readable without signing into a provider app.
It is independent of any one app

App accounts close, apps retire — the consumer remittance space has consolidated more than once — and devices break. The sender's record does not depend on one provider staying available.
It spans every provider at once

A sender using Wise for a bank deposit and Western Union for a cash pickup to an unbanked recipient cannot get a single cross-provider view from either app. The sender's own log is the only place that view exists.

The cycle anchor: payday or the recipient’s cut-off

A monthly padala needs an anchor, and what the log needs from either option is only that it stays the same month to month. One anchor is the sender’s payday. Paydays do not line up across countries or industries — a US sender paid bi-weekly, a UAE sender paid month-end, a Canadian sender paid semi-monthly all have differently shaped “months,” so a calendar month-end entry can land anywhere in the income cycle while a payday-anchored entry lands in the same place relative to income every time.

Where the recipient has a fixed obligation date, the second anchor is the recipient’s cut-off. Tuition is due on a set date; a bill cycles on a set date; the rent the recipient pays from the padala has a deadline. The system can sit on either anchor, or on a hybrid — sending early in the payday cycle to land before the recipient’s cut-off — as long as the anchor is consistent.

The FX-rate column

Logging the effective FX rate at each transfer is an optional, retrospective audit column. This page states no view on timing transfers around expected rate moves. What the per-transfer rate does is let the annual roll-up show the weighted-average effective rate a sender achieved across the year, set against the World Bank Remittance Prices Worldwide tracker’s quarterly corridor-level posted total cost — fee plus FX margin — across providers (worldbank.org; checked 2026-08-08).

Where a sender’s effective rate consistently runs behind the World Bank US→PH corridor average, a year of dated entries is what makes that visible, at the provider and channel level. It is a reading of what already happened, not a prediction, and what to do with it is the sender’s. For the cost comparison itself, the cheapest way to send money, the apps vs banks vs padala comparison, and the cash pickup vs bank vs e-wallet pages cover the channel-level analysis.

The four silent failures

Where a monthly padala record quietly breaks

Reference number not captured at send time — the recipient cannot collect a cash pickup, and the sender cannot dispute a missed payout from an offline log.
Confirmation loop not closed — the line is marked sent on the provider's 'transfer complete' status, never confirmed with the recipient that the payout landed.
Multi-corridor currency confusion — a co-sender remitting in AED logged into the same sheet as a primary sender remitting in USD, and send-side amounts added as if they were one currency.
Sole reliance on provider-app history — the only record sits inside one provider's app, with no independent mirror; the account closes or the app retires, and the history goes with it.

How the monthly log rolls up over a year

A year of monthly rows produces four retrospective figures the system makes visible:

Total remitted in the sending currency across the year.
Total fees paid — the explicit sender-paid cost of that year’s channel choices, separate from the FX margin.
Weighted-average effective FX rate across the year’s transfers, comparable to the World Bank US→PH corridor figure for the same period.
Payout-method mix — the bank deposit / cash pickup / e-wallet shares across the year. A sender can read their own mix alongside the mode-of-remittance tables the PSA Survey on Overseas Filipinos publishes (psa.gov.ph; checked 2026-05-21); whether an individual sender’s mix matches the national pattern is a once-a-year reading, not a target.

These are retrospective audits, not budget targets. What share of a paycheck the padala takes is the OFW monthly budget split question, which states no figure or percentage. The two pages pair: the budget split structures what goes out; the tracker records what went out and what arrived.

Where this sits next to the national figures

The tracker is sender-side. The orientation page on how much OFWs collectively send home covers the aggregate side — the BSP cash remittance series, the PSA household survey, the World Bank cross-country anchor. A sender who has tracked a year of monthly rows can read their own annual roll-up alongside the published BSP and PSA series for context; the two are different scales — one household, one national aggregate — and the comparison is contextual, not normative. The rest of the money-side reference sits in the OFW money section.

How to read this

This page is a structural reference for a sender-side monthly padala log. It does not recommend an amount, a cadence, a provider, or a tool — those are the sender’s own. The seven columns and the closing step are what turn a partial record into a tracking system; the optional columns named above accumulate audit value over months. The page is re-verified at least yearly; the lastChecked date in the frontmatter is the floor on every claim above. The AMLA five-year provider-side retention is a durable statutory reference; the PSA SOF mode-of-remittance tables and the World Bank corridor data move and live on the source pages.