A financial export contains transactions and subtotals: count each amount once

An accounting report exported for reading may include transaction lines, account subtotals, department totals and a grand total in the same amount column. Importing every numeric row into an analysis or journal can count the same business activity several times. Identify what each row represents before interpreting the sum.

Save the original export and the report settings used to create it. Look for an explicit record-type field, transaction identifier or documented structure that distinguishes detail from summaries. Bold type, indentation and blank dates can be useful clues, but they are weak foundations for a repeatable import rule.

For an illustrative account, two transactions of $120 and $80 are followed by a $200 account subtotal. Summing all three rows yields $400. Adding a further report total can increase the overstatement again. The duplicated economic amount comes from mixing levels of aggregation, even though every displayed number is individually correct.

Choose a section of the actual export and identify the detail that supports its subtotal. Compare the detail-only result with the printed summary. If they differ, investigate exclusions, signs or scope before assuming the subtotal is wrong. The export may include opening balances or another row type that needs a separate rule.

Microsoft documents that Excel's SUBTOTAL ignores nested SUBTOTAL calculations in its referenced range to avoid double counting. That behavior depends on the formulas. A pasted-value export containing a number labeled subtotal does not carry the nested formula relationship that the function recognizes.

Microsoft also distinguishes manually hidden rows from filtered-out rows in SUBTOTAL behavior. Check the formula choice and active filters when using it as a control. Hiding an unwanted total row is not a substitute for understanding which records the calculation includes.

Ask whether a detail-only export is available from the source system. If it is, compare its population with the readable report and retain both for their respective purposes. If a transformation is required, make the row classification explicit so the next report period does not depend on manual deletion.

A useful transformation can retain reported subtotals in a separate control dataset while passing only approved detail rows onward. Reconcile the detail by account, entity and currency to the corresponding source controls. Do not combine different currencies into one unexplained check total.

Avoid removing rows merely because their amounts repeat. Two valid transactions can both be $200, and a legitimate transaction can equal an account subtotal. Classification should rely on the row's identity and meaning, with ambiguous records held for review instead of guessed into or out of the population.

Test a report with several subtotal levels, a zero-activity account, a negative balance and a changed page layout where those cases are supported. Include a transaction description containing the word total. A text rule that excludes every occurrence of that word can discard legitimate activity.

Compare accepted detail identifiers and amounts with the approved transformation. If an earlier upload already posted summary rows, have the accountant identify and approve the required correction. Deleting rows from the source file does not reverse entries already in the ledger.

Keep the row-type rule, excluded-summary controls and final reconciliation together. The next preparer should be able to explain which rows create the financial population and which rows only verify it, even when the export's appearance changes.