<h2>Reviewing travel transactions after PDF extraction</h2>


A trip often leaves its financial trail in several places: a card statement, a booking confirmation, a rail ticket, a hotel receipt and a refund email. The statement is useful because it records the account activity, but it is not a complete travel diary. A payment may settle days after the journey, a booking merchant may have an unfamiliar trading name, and a temporary authorisation may never become a settled charge. Turning the statement into a spreadsheet helps organise the evidence, provided that the extracted rows are checked before they are treated as reliable records.



This is a practical data-review workflow for people preparing a trip expense table. It is not a recommendation about banking products, a tax eligibility statement or a promise that any extraction system will recognise every document perfectly. The aim is to keep the original evidence available, make uncertainty visible and avoid importing a plausible-looking mistake into another system.



<h2>Keep the source and define a small review batch</h2>


Begin with an unchanged copy of the original statement and the date range it covers. Store the conversion output separately so that sorting, filtering and correcting the spreadsheet cannot overwrite the source. If you are experimenting with a new tool, use a redacted or non-sensitive sample first. Read the tool's current privacy information before uploading a document containing account identifiers or personal transaction details. A convenient workflow is not a reason to ignore the sensitivity of the input.



Choose a manageable batch rather than mixing every account and every holiday into one sheet immediately. One statement period is a sensible starting point. Record the source filename, account currency and review status in a small working note. If the document contains several accounts or cards, retain those distinctions. They may explain similar transactions that would otherwise appear to be duplicates.



<h2>Treat conversion as the beginning, not the conclusion</h2>


The extraction stage should produce a table that can be compared with the PDF. Depending on the document, that may involve selectable text, a scanned page or a mixture of both. One browser-based resource to investigate for this stage is bankstatementconverter. Evaluate the current interface and output options against your own document rather than assuming that every bank layout behaves identically. The review principles below apply regardless of which conversion utility you choose.



After extraction, keep an untouched copy of the initial output as well as the reviewed version. This makes later corrections explainable. If a description was joined to the wrong row, you can show what changed instead of trying to reconstruct the first result from memory. A simple note such as &ldquo;description continued across page boundary&rdquo; is more useful than silently replacing the value and forgetting why it differed from the source.



<h2>Separate transactions from balances and summaries</h2>


Statements often place an opening balance, a closing balance and a monthly summary near the transaction table. Those values are important for reconciliation, but they should not automatically become additional expense rows. Identify the table's genuine boundaries. Check whether the first and last extracted rows correspond to real transactions, especially when the statement includes a page total between two sections of the same table.



For travel expenses, a summary of foreign spending can be particularly misleading if it is mixed with the individual charges that it summarises. Adding both produces double counting. Keep summary values in a separate review area with their original labels. Do not classify a row as a payment merely because it contains a date-like number or a monetary amount; inspect how that value is presented in the PDF.



<h2>Check dates without confusing settlement and activity</h2>


A train reservation made in one month may be charged in the next. An overseas card payment can also have a transaction date and a separate posting date. Preserve both when the statement provides them, and give the columns clear names. Decide which date your trip worksheet uses for grouping, but keep the other date available for traceability. Moving an amount into a different reporting month without retaining its source date makes later checking harder.



Also confirm whether the printed format is day/month or month/day. A date such as 04/05 is ambiguous without context. Look at unambiguous neighbouring dates and the statement's own format, not just the spreadsheet application's regional defaults. Check year boundaries on trips that cross December and January. A missing year should not be filled from today's date merely because the software finds that convenient.



<h2>Preserve currencies, direction and signs</h2>


A statement may show the merchant's original currency alongside the final amount charged in the account currency. Keep these as distinct fields if both are present. Do not add an original-currency amount to an account-currency total, and do not invent an exchange rate to make a discrepancy disappear. Conversion fees may be included in a charge or listed separately, depending on the issuer's presentation.



Inspect an ordinary outgoing payment and an incoming refund before applying sign rules to the entire sheet. Separate debit and credit columns are not equivalent to a single signed amount column. Brackets, a trailing minus and a credit marker can have different meanings across document layouts. Retain the original representation while reviewing the normalised amount. If a refund appears positive in one column, explain its direction in your reviewed model rather than guessing from the merchant name.



<h2>Read descriptions and investigate apparent duplicates</h2>


Booking references and merchant descriptions can wrap across lines. A continuation line should stay with its transaction rather than shifting the next amount into the wrong description. Inspect examples around page breaks, where headers, footers and repeated column labels can interrupt the table. Long hotel and airline descriptions deserve a spot check because truncation may remove the part that distinguishes one booking from another.



Two matching amounts are not sufficient evidence of a duplicate. They could be separate tickets, split payments, a deposit followed by a balance payment, or a charge followed by a reversal. Compare dates, direction, references and supporting receipts. Keep uncertain pairs in an exception list. Deleting one row to make a total look tidy replaces an unresolved question with a potentially incorrect conclusion.



<h2>Reconcile before organising the trip categories</h2>


Where the statement provides compatible opening and closing balances, compare those balances with the signed transactions using the issuer's own conventions. This is a check on the table, not a guarantee that every description is accurate. A mismatch should lead to inspection of missing rows, repeated totals, fees and sign interpretation. Never create an invented balancing transaction simply to obtain a matching number.



Only then add working categories such as transport, accommodation or meals. Keep categories separate from the original merchant text, and leave unclear transactions unclassified until there is supporting evidence. A booking platform may collect payments for several kinds of service. Categories are your interpretation; the statement description is source evidence. Preserving both makes it easier to revisit a decision without repeating the extraction.



<h2>Keep an exception list and a clear final handoff</h2>


Finish with a short exception list identifying anything still unresolved: an unreadable scanned amount, an uncertain date, a missing receipt or an apparent reversal. Include the relevant source page or reference so that another reviewer can locate the issue. Mark a row as reviewed only after the needed check has actually been completed. A separate review-status column is better than relying on cell colours whose meaning nobody has written down.



Before importing the table elsewhere, inspect the final row count, column names, date format and currency handling. Keep the original PDF, initial extraction, reviewed table and correction notes together according to your own document-handling policy. The useful result is not merely a spreadsheet that opens successfully. It is a table whose important values can be traced back to the statement, with remaining uncertainty visible rather than hidden by automation.