Payroll Import Files: Approve the Version, Verify the Result
Updated: Nov 3
The file that payroll imports should be the exact file the reviewer authorized. Preserve that candidate, connect the approval to its version, inspect the import's actual results and compare the resulting payroll inputs with the approved instructions. A successful upload does not establish that the right people, periods or amounts reached the run.
Payroll import file governance is the process for controlling that chain. It applies to a time export, a bonus worksheet, a deduction batch or another file that changes payroll data. The review needs to establish what the file may change, which source supports it, what the importer does with it and how the team will resolve anything that does not arrive correctly.
This guide is for U.S. payroll teams that exchange files with time, HR, finance, benefits or external service providers. The release record and worked import are original operating examples. They are not a universal upload specification, a tested product result or authority to change an employee's pay treatment. Use the instructions for the actual product, account and type of import.
When import problems are prompting a payroll software review, bring the file types, approval boundaries and recovery evidence you need. A free SelectSoftware Reviews advisor consultation can help identify payroll options to investigate. Ask each prospective provider to demonstrate its own import and correction process.
Contents
Define what one import is allowed to change
Give each import a defined payroll purpose before checking its columns. Identify the employing entity, payroll group, pay date, source period and destination. State whether the file supplies hours, an earning amount, a deduction instruction, a costing allocation or another approved change. Two files with identical headers can have different consequences when they target different runs.
Describe the population as well as the date range. Does the extract include all active employees, only workers with approved time, or only changes since the preceding export? Are leavers, newly assigned employees and people with no activity included or deliberately absent? A zero-activity employee and a missing employee should not become indistinguishable simply because neither produces a row.
Name the authoritative source for each imported field. Timekeeping may supply approved hours while HR controls the employment identifier and payroll controls the earning-code mapping. A file preparer can assemble these values without having authority to invent a new code or change the effective date of an employment instruction.
Keep the boundary narrow enough to review. If one workbook contains hours for several employers, produce and identify the correct release candidate for each destination rather than relying on a tab name to keep employers separate. If the process genuinely uses a combined file, require a supported employer identifier and an employer-by-employer comparison.
Keep the source extract and the release file distinct
Retain the received source separately from the file prepared for import. The source establishes what was supplied; the release candidate establishes what someone approved for this particular load. If payroll transforms the source, record the transformation instead of making the original extract disappear.
For example, a source might report approved time by workday while the importer expects a total by employee and earning code. Preserve the extraction parameters and the grouping rule. Record any excluded rows, identifier translation or approved adjustment. The reviewer needs to reproduce the candidate's population, not merely open a spreadsheet with plausible totals.
Assign a short release identifier, such as PAY-1106-02, and retain the exact saved file under it. Include its generation time, source cutoff, revision and responsible preparer in the release record. Use an approved storage location whose permissions and version history support the review. A filename ending in final can be changed or copied; it cannot carry the approval by itself.
Where the tools permit, record a file hash or another unambiguous version identifier with the approved copy. A hash can help compare copies; it does not establish that the contents were authorized or correct. Teams without a hashing process can still retain an access-controlled release copy and an exact storage revision reference. Do not substitute a screenshot of the workbook for the file that will actually be uploaded.
If an approved late change arrives, create a new candidate and identify what it supersedes. Preserve the earlier candidate and its decision. The new version needs the affected validation and approval checks again, including a check of which earlier versions have already been imported.
Each release stage answers a different question. A changed candidate returns to file approval; successful import execution still needs payroll review.
Read the import contract before deciding how to correct it
Understand the destination's rules before using a file in production. Obtain its current template, required identifiers, field meanings, supported dates, units and result reports. Establish whether the operation adds records, updates matching records, replaces a defined population or follows another documented method.
Those distinctions determine the recovery plan. Oracle's current time-card update documentation, for example, describes Update and Delete and Create methods controlled by the time-element setup. That product-specific behavior is a reason to check the actual configuration. It is not evidence that another payroll product will recognize a repeated file or safely replace what an earlier attempt loaded.
Write down the matching keys used by the importer, including any employer, assignment, period or source-record identifier. Ask how duplicate rows are detected, what a second submission does and whether a failed batch can leave accepted records in the destination. If the documentation or service contact cannot establish the committed state, treat that state as unresolved before attempting recovery.
Also establish what the result screen means. Uploaded, parsed, validated, accepted and applied can describe different steps. Identify the report or destination view that shows the records created or changed. Oracle's time-card import guidance identifies both the process results listing transferred time-card IDs and the calculation-card view of the transferred entries. Use the equivalent evidence for your actual product rather than assuming that the file picker confirms the result.
Keep vendor-specific instructions beside the record for that interface. This guide supplies control questions, not a replacement sequence of buttons. A procedure for importing employee hours should not be borrowed for importing contractor payments, historical balances or bank instructions merely because each accepts a CSV.
Check the saved file, not just its workbook
Review the exported artifact in a way that preserves its data types. Microsoft documents that Excel can remove leading zeros, change numerical text into numbers and interpret some text as dates. An identifier intended as 00123 therefore needs an explicit preservation check; displaying extra zeros later does not establish that the original value survived.
Compare identifiers as identifiers. Verify the exact approved employee or assignment key, including leading zeros, and test the destination's required date and decimal conventions. Do not match employees by row position or by an abbreviated name when the interface expects a stable identifier.
Units deserve their own check. Confirm whether a value is decimal hours, minutes, days, units, a rate or a payment amount. For a decimal-hours field, one hour fifteen minutes is 1.25 hours, not 1.15. That arithmetic does not mean every importer accepts decimal hours or that every source should be converted the same way. Apply the documented field definition and preserve the conversion rule.
Open or preview the saved import candidate, not just the preparation workbook. Microsoft's CSV guidance explains that the format saves only the active sheet's text and values as they are displayed, losing formatting and other workbook contents. Colored review cells, worksheet comments and a formula-driven approval flag are not a dependable authorization trail inside the exported CSV.
Check headers, column order where required, encoding, separators, blank values and the saved population. Confirm that exporting did not include a hidden helper column or omit a required column. Preserve a review workbook if it explains calculations, but make the sign-off identify the actual import artifact and the validation of that artifact.
Reconcile populations and separate totals before approval
Use several comparisons because each answers a different question. Count submitted data rows separately from distinct employees, assignments or other business records. One worker may legitimately have several earning rows, so a 100-row file does not establish a population of 100 employees.
Reconcile the candidate to the approved source by employer, period and relevant code. Keep regular hours, overtime hours, payment amounts and other quantities on separate lines. Adding hours to dollars produces a total with no useful meaning. If an import contains positive and negative adjustments, review the components as well as the net.
A matching total can conceal a wrong allocation. Suppose two approved entries are 40 hours each, but the candidate contains 36 for one worker and 44 for the other. Both versions total 80 hours. The control total passes while both employee-level instructions are wrong. Use record-level comparisons for the fields the file changes, alongside broader reasonableness checks.
Identify expected absences deliberately. If a source has 60 workers and the candidate has 59, explain the difference before upload. A documented exclusion might be correct; an unexplained missing person is still an exception even when the file's total amount looks close to a prior period.
Make the review repeatable. Retain the source report parameters, transformation version, candidate totals and comparison results. A small batch may support a complete manual check. A larger batch may need a controlled comparison routine plus targeted review of new people, new codes, unusual amounts and other exceptions. Volume alone should not turn an unexplained difference into an accepted one.
Authorize the exact candidate and control later edits
Record the decision to import before the upload. The approver should see the candidate's scope, source approval, validation results and unresolved exceptions, and identify the exact file or storage revision being authorized. Record the uploader and destination separately so the handoff is visible.
Apply access according to the person's task. NIST's least-privilege principle limits authorizations to what the assigned function requires. For an import process, distinguish preparing a candidate, changing the mapping, approving the file and uploading it. These are useful control responsibilities; they are not a claim that every payroll product exposes four matching permission switches.
A small payroll team may combine roles. If it does, record the combination and arrange a meaningful review by the owner, controller or another appropriate person. Give that reviewer evidence they can actually assess, such as source totals, changed identifiers and destination results. A second name on the record is not useful if the person cannot see the information needed for the check.
Protect the approved candidate from casual editing. If someone changes a value, regenerates the export or swaps the destination after authorization, stop using the old sign-off as if it covered the changed operation. Produce the replacement candidate, show the differences and obtain the necessary approval.
Keep approval timing practical. Set a source cutoff, a review window and an escalation contact before payroll day. Authorization to import a file remains separate from authorization to release payroll or a bank payment. The import can be correctly executed while the pay run still requires review.
Compare providers against the records you need
If import controls are part of a provider search, describe your version approval, validation and result-reporting requirements to SelectSoftware Reviews. Ask prospective providers to demonstrate a rejected row and a safe correction.
Inspect the destination before retrying a partial load
After the attempt, capture its identifier, time, submitted file and reported outcomes. Compare submitted rows with accepted, rejected, skipped and other statuses using the importer's definitions. Do not count an unreported row as accepted simply to make the totals balance.
Establish whether accepted rows were committed to the destination and whether any rollback has actually completed. A timeout or an incomplete status screen leaves the result unknown. Preserve the attempt details and contact the responsible service or system owner before making another submission that could repeat committed records.
Oracle's U.S. payroll instructions illustrate why a correction needs a source and product-specific recovery route: its time-entry process describes correcting the underlying source problem and using the applicable rollback and transfer steps. Do not copy that procedure into a different importer or treat a local payroll edit as a universal fix.
When partial recovery is supported, identify the exact remaining source rows and prepare a controlled correction or retry file. Keep its relationship to the original batch visible. Confirm that the same affected row is not also scheduled through a manual entry, another interface or a separate payroll.
If a full replacement is the supported method, verify its replacement scope and prior-record treatment before using it. Do not submit a full file merely because producing it is easier than identifying what the first attempt already applied. When the committed state or replacement behavior is still unclear, keep the recovery decision open and escalate it with the attempt evidence.
Work through a 100-row import and a two-row correction
The following example is fictional. It assumes an importer for which the team has confirmed that accepted rows remain committed and that an approved retry can contain only rejected rows. It does not describe a particular vendor's behavior.
The approved candidate PAY-1106-02 contains 100 earning rows for 60 workers. The separate totals are 2,200 regular hours, 80 overtime hours and $3,000 of bonus amounts. The preparer retains the exact candidate and its source comparison; the reviewer authorizes that version for the defined payroll.
Attempt A reports 98 committed rows and two rejected rows. The accepted totals are 2,160 regular hours, 80 overtime hours and $2,800 in bonus amounts. Rejected row R044 contains 40 regular hours and needs a corrected employee identifier. Rejected row R077 contains a $200 bonus and needs the approved earning-code mapping. Those two exceptions explain the missing quantities without mixing hours and dollars.
The team confirms the source identifiers and mapping with their responsible owners. It creates a separately identified correction candidate containing only R044 and R077, retains the changes and obtains authorization for that limited retry. Attempt B applies both corrected rows.
The coverage now reconciles: 98 plus 2 equals the intended 100 rows. Regular hours are 2,160 plus 40, or 2,200; overtime remains 80; bonuses are $2,800 plus $200, or $3,000. The reviewer also checks the employee and code detail in the payroll preview and verifies that the intended 60 workers are represented. Matching these totals is necessary, but it would not detect the 36-versus-44-hour allocation error described earlier.
Under this example's append behavior, blindly submitting another full 100-row file after correcting it could create 198 committed rows: the earlier 98 plus another 100. That would repeat 98 entries. A different importer could replace or reject matching rows, which is precisely why the actual behavior belongs in the release record before recovery.
This comparison assumes the fictional append behavior described above. Establish the real importer's committed state and retry rules before choosing a recovery file.
Carry unresolved items into a cutoff decision
Give each unresolved row a reason, owner, next action and deadline. Distinguish a source error from an interface-format problem, a missing approval, an unknown import outcome and an accepted record that appears incorrectly in payroll. Each needs a different person and a different acceptance test.
Do not make local corrections invisible. If a permitted payroll-side adjustment is needed, record its authority, affected employee, amount or quantity, destination and relationship to the source row. Assign the upstream correction and verify it before the next export so that the temporary adjustment does not return as a duplicate.
Consider the effect of holding part of a batch. A separate employer or an unrelated earning might be isolatable under the documented process. A correction to one worker's regular hours may also change calculations or other reviewed results. Confirm the dependency rather than declaring every non-rejected row ready for payroll release.
A file hold does not decide when an employee should be paid. If recovery threatens the intended pay date, escalate the affected population and the actual remaining work to the people responsible for payment timing and legal requirements. Determine an authorized, timely route for the affected pay; do not assume that leaving the input for the next cycle is acceptable.
Close an exception only after its acceptance test passes. An identifier corrected in the source is progress. The complete result also needs the intended entry in the destination and the applicable payroll review. Retain superseded attempts so a later reviewer can see why the final run differs from the first upload.
Use a Payroll File Release Record
Copy one record for each release candidate and connect correction attempts to their parent batch. Complete fields 1 to 8 before authorizing upload. Complete fields 9 to 12 from the actual destination and payroll results. A blank outcome field means the corresponding result is still unverified.
File and import contract
1. Payroll boundary: Employer, payroll group, pay date, source period, destination and permitted change: ______.
2. Approved source: Source owner, approval reference, extraction parameters and cutoff: ______.
3. Exact candidate: Release ID, saved filename, storage revision or hash, generation time and superseded version: ______.
4. Import behavior: Current template, matching keys, units, add/update/replace method and documented retry treatment: ______.
Identity note: keep the received source, the prepared candidate and the uploaded artifact connected without overwriting their different histories.
Pre-upload authorization
5. Field authority: Approved identifiers, earning or deduction mappings, effective dates and transformation rules: ______.
6. Candidate comparison: Row and worker counts, separate quantity and amount totals, record-level checks and explanations: ______.
7. Open conditions: Affected rows, dependency, owner, payment-timing escalation and next action deadline: ______.
8. Import authorization: Exact candidate approved, approver, decision time, uploader, destination and any limits: ______.
Approval note: a changed file or destination needs the affected checks again; approval to import is not approval to release payroll.
Destination and closure
9. Attempt evidence: Attempt ID, submitted file, result time, accepted/rejected/skipped rows and confirmed committed state: ______.
10. Recovery evidence: Parent attempt, specific correction rows, source fixes, approval, retry or rollback result and duplicate check: ______.
11. Payroll comparison: Intended entries in the preview or register, employee/code differences, reviewer and remaining conditions: ______.
12. Final disposition: Cleared or held items, evidence reference, responsible owner, next deadline and retained records location: ______.
Closure note: preserve pending items explicitly; an accepted upload cannot stand in for the later payroll comparison.
Filled notes for the fictional batch
A. Authorized candidate: PAY-1106-02 has 100 rows for 60 workers; 2,200 regular hours, 80 overtime hours and $3,000 bonuses.
B. First attempt: Attempt A committed 98 rows and rejected R044 with 40 regular hours and R077 with a $200 bonus; the accepted totals explain both omissions.
C. Recovery and review: The approved two-row correction brings coverage to 100 rows and restores each separate total; employee/code detail and other payroll review still require their recorded checks.
The filled notes illustrate the record. They do not establish an actual import, product capability, pay calculation or approval for a real payroll.
Retain a usable record without duplicating the payroll database
Keep the approved source references, exact release candidates, approvals, validation results, import receipts, correction history and destination comparisons together or connected by durable references. A reviewer should be able to follow one row from its source instruction to its actual payroll effect without relying on a person's recollection.
Use different access for different needs. The operational release record can identify a restricted source file and summarize a difference without copying a full employee dataset into a broadly shared folder. Provide the uploader and reviewer with the data they need through approved access, and avoid adding bank or government identifiers merely to make a control sheet look complete.
Apply retention by the kind of record and the obligations it supports. The IRS employment-tax recordkeeping page currently calls for at least four years after filing the fourth quarter for the year and identifies records to retain, including wage-payment details and relevant tax records. It also identifies longer retention for certain credit substantiation records. That does not classify every working export as the same record or replace applicable state, privacy, contract or litigation requirements.
Set the employer's retention and deletion instructions for original sources, release evidence and temporary working copies. Include access after a provider change and a way to retrieve the mapping instructions used at the time. A current template alone will not explain an older import made under a different version.
Change the process when the same exception keeps returning
Review repeat rejections and manual fixes by source, field and cause. A recurring identifier mismatch may need a corrected source mapping or an ownership decision. Repeated last-minute file replacement may need an earlier source cutoff and a reliable release location. Repeated uncertainty after upload calls for better attempt evidence or a clarified recovery procedure.
Recheck the interface when a template, payroll product, earning code, employer population or source extraction changes. Use an approved sample or a permitted test to demonstrate the affected transformation, validation, rejection and retry behavior. Record what the demonstration establishes and which production checks remain; do not create unnecessary real pay or bank movements to prove that a CSV can be loaded.
Automation can reduce repeated preparation work, but it should retain the same decision trail. The team still needs to know which source version ran, which mapping applied, what the destination accepted and who handles the exceptions. An unattended transfer that hides those facts can make a high-volume failure harder to contain.
Keep a controlled manual route when the volume and exception workload are manageable. Where the existing system cannot provide usable results, permissions or a documented recovery path, bring those requirements into a provider or integration review. Choose the change that addresses the observed gap, and keep the employer's source and payroll approvals explicit after the change.
Use your requirements to guide the provider search
Bring the requirements from your Payroll File Release Record to an optional SelectSoftware Reviews conversation. Verify the actual import behavior and recovery evidence with each prospective provider.
Explore related payroll resources:
About the author
Ben Scott writes and maintains payroll decision guides for founders and operators. His work focuses on execution realities and how decisions hold up under growth, complexity, and controls and documentation pressure. He works hands-on in HR and leave-management roles that intersect with payroll-adjacent workflows such as benefits coordination, cutovers, and compliance-driven process controls.
