Financial Systems Field Guide for Contractors

Foot the exported detail to a documented control total, verify the expected date and status population, and preserve the original file and fingerprint.

Include the source, entity, report, cutoff, filters, statuses, row count, control total, schema, filename, fingerprint, preparer, and exception status.

Hash the original download and compare that fingerprint, file size, row count, schema, and control total before using a later copy.

Compare both row identities and integer-cent totals to the same documented population. Matching only one does not prove completeness.

No. An API can be incomplete, filtered, stale, or changed, just like a CSV. Authority comes from the defined population and verification, not the transport.

Assign a source of truth separately for each fact. Keep the operational creator, accounting posting, and reporting mirror linked by stable identifiers.

Record the report name, entity, as-of time, date basis, statuses, filters, currency, timezone, and person or process that produced it.

Use an expected delivery calendar, unique period key, file fingerprint, row count, and control total. Missing or repeated period keys should fail visibly.

Yes, only with page and session checks, expected columns, completed-download verification, source preservation, and population controls that fail on change.

Compare extracted values with the source pages or cells, foot totals, retain provenance and confidence, and route ambiguous or material fields to review.

AR differs when the two reports use different invoices, payments, credits, write-offs, statuses, dates, customers, or cutoffs. Reconcile open-item detail first.

Trace each invoice through deposits, payments, applications, credits, write-offs, and the remaining balance using stable record IDs and one cutoff.

A workflow may mark operational work closed while a credit, payment application, retainage amount, or accounting balance remains open.

Unapplied cash reduces bank or customer exposure without reducing a specific invoice, so customer and aging views can disagree until it is applied.

Duplicate customer masters split invoices, payments, credits, and balances across identities. Use an approved crosswalk before merging or reapplying records.

Compare completed jobs with issued invoices for the same cutoff, then exclude legitimate approval, change-order, contract-billing, and cancellation states.

Compare the complete eligible field invoice population with accounting by source invoice ID, amount, status, date, customer, and exception outcome.

Freeze the legacy open-item list at cutover, map customer and invoice identities, reconcile applications and balances, and foot the target AR control account.

Foot customer opening-balance detail to the conversion control total, then prove each customer, document, date, application, and open amount in the target.

The control total can tie while invoices or payments sit under the wrong customer. Compare record identity and customer assignment, not only the aggregate.

Freeze the legacy open-bill population, reconcile vendors, bills, credits, payments, applications, aging, and the AP control account in the target.

Compare each vendor and open document to the legacy cutoff, then foot target open-item detail and the AP control account to the approved conversion total.

AP aging can differ from the GL because of cutoff, posting, voids, credits, manual journals, currency, status filters, or transactions outside the subledger.

Migrate open vendor credits and unapplied payments as identifiable open items, preserving vendor, document, date, amount, currency, and application status.

Duplicate vendor masters can split controls and let the same obligation enter approval or payment twice. Block payment until identity is resolved.

Keep PO, receipt, bill, credit, approval, and payment as distinct linked events. Do not collapse them into one status or assume one proves another.

Carry stable job and cost-code identifiers through the bill import, reject unmapped values, and read the posted target detail back before approving the result.

Classify each refund or recovery by its economic source and related job or expense. Do not default every receipt to income or net it without evidence.

Compare source payment, target payment, bill applications, cash account, date, amount, vendor, and target read-back. An accepted import is not proof.

Use an approved vendor crosswalk supported by tax ID, address, bank evidence, document history, or another stable identifier. Name similarity alone is insufficient.

Require exact native IDs or approved crosswalks whenever they exist, especially for automated posting, cash application, duplicate prevention, and migration.

Fuzzy matching is safe for proposing candidates, not approving identity. Require supporting fields and human review when more than one candidate is plausible.

Prefer native IDs, then entity, account, document reference, counterparty, date, currency, integer-cent amount, and an approved accounting relationship.

Prove the payer and exact invoice subset with remittance or equivalent evidence, make the integer-cent total foot, and consume each invoice once.

Prove the ledger event and exact bank-line group, including dates, amounts, account, and settlement evidence. Leave it unresolved if another group also fits.

Treat both combinations as ambiguous. Do not select the closest set until remittance or another authoritative source establishes the intended invoices.

No. A one-cent difference may be a fee, withholding, short payment, credit, or separate error. Preserve it as an exception until supported.

Maintain a one-use constraint on each source transaction and reject any candidate that consumes a bank line or ledger item already actively matched.

Generate supported groups, require exact footing and compatible evidence, prevent double use, and stop without posting when multiple valid groups remain.

Run the same frozen fixture in different input orders and environments, then compare normalized matches, exceptions, totals, and refusal outcomes exactly.

Reconcile open AR and AP, cash, payments in transit, active jobs, WIP, fixed assets, payroll liabilities, tax balances, retained history, and opening equity.

Use one cutover cutoff and compare legacy detail, conversion records, target subledgers, GL control accounts, and target reporting read-back.

Define which active-job, cost, billing, commitment, WIP, retainage, and history fields the target needs, then prove the converted population and balances.

Post conversion balances through separately identified records or accounts and reconcile later activity by original economic date and target posting date.

Import what the target needs to transact, collect, pay, report, and explain. Preserve the rest in a controlled archive with stable links and access tests.

Map every old account to an approved target account, test sign and statement placement, foot balances, isolate exceptions, and review the first close.

Migrate only governed values with stable crosswalks, preserve hierarchy and inactive status, reject unmapped records, and verify the dimensions on target postings.

It is complete only after the target accepts it, detail foots, exceptions are resolved or owned, control accounts agree, and target reporting read-back passes.

Repeat AR, AP, cash, payroll, WIP, revenue, expense, and balance-sheet reconciliations using the first live cutoff, including conversion and current activity.

Retain source exports, manifests, mappings, approvals, exceptions, transformations, import logs, target read-back, and the reason for material policy choices.

Use the path that reflects the real transaction flow. A clearing account is useful for a defined handoff, but it is not a universal requirement.

Trace one pay run from register through journal, liabilities, settlement, bank feed, match, and job cost. Do not add the bank withdrawal as a second expense.

Foot the payroll journal and liabilities to the actual cash settlements by pay run and cutoff, explaining outstanding timing items until clearing is resolved.

Define wage, tax, benefit, insurance, and other burden components, then allocate them to jobs using an approved basis and reconcile back to payroll and GL.

Aggregate payroll can tie while employees, jobs, classes, cost codes, or periods are wrong. Compare detailed identities and assignments as well as totals.

Foot gross pay, employer taxes, deductions, liabilities, reimbursements, and net cash by pay run to the GL, payroll clearing, and bank settlement.

Map each component by economic purpose, liability or expense treatment, entity, employee, and job-cost policy, then test a full pay run end to end.

Compare imported time and labor by employee, job, date, earning type, hours, rate, burden basis, and posting result, including rejected or duplicated records.

Accrue earned payroll and related burden under the company policy, then reverse or settle it against the next payroll without duplicating expense or job cost.

Only supported timing items should remain. Every balance needs a named pay run or liability, amount, expected settlement date, and owner.

A connector can move valid messages while the wrong population, mapping, period, dimension, or accounting treatment produces an unreliable financial result.

Reproduce one record, inspect logs and target read-back, and compare configuration, mapping, filters, permissions, and timing before classifying a vendor defect.

Test create, update, cancel, duplicate, partial payment, credit, write-off, offline recovery, cutoff, mapping, rejected record, and target read-back paths.

Status filters define record eligibility. A technically successful sync can omit valid records or include premature ones when those rules differ from reporting.

They change open balance and application state. Preserve the original invoice and link each settlement event so both systems explain the same remaining amount.

Use an owned exception queue with source ID, error, first seen time, retry state, financial impact, next action, due date, and resolution evidence.

Read-only retrieves data, staged-write prepares a reviewable change, and write-enabled can alter the target. Approval and read-back controls should increase accordingly.

Periodically compare incremental results with a full same-cutoff source population, stable IDs, counts, and control totals to detect skipped or replayed records.

Freeze affected writes, preserve payloads and errors, version the schema mapping, backfill from a known cutoff, reconcile the full population, and verify target read-back.

Use vendor support for documented product defects, access, connector behavior, and platform errors. Use a finance-systems advisor for source ownership, accounting treatment, controls, reconciliation, and close design.

Yes, for extraction, classification, candidate matching, and explanation, when source evidence, deterministic controls, human approval, and target read-back remain authoritative.

AI can propose classifications, matches, mappings, explanations, and draft entries. It should not alone approve accounting identity, policy, payments, or posted corrections.

Record the model and version, source IDs, prompt or rule, extracted fields, confidence, candidates, transformation, reviewer, decision, and final target result.

It means retrieving the posted target record and resulting financial report after the action, then comparing them with the approved change and source evidence.

Use freshness timestamps, expected update cadence, source row counts, recent known activity, ingestion logs, and a deliberate no-activity state. Missing data is not zero.

Run source freshness, population footing, duplicate, cutoff, mapping, subledger-to-GL, cash, exception ownership, and target read-back controls before release.

Give every material exception a stable ID, type, impact, owner, next action, due date, status, evidence, and verified resolution. Unknown is a valid state.

Mutation-test it by breaking a frozen fixture in the way the control claims to detect. The control passes only if the broken case fails and the correct case passes.

Keep client values in governed configuration with schema, validation, version, approval, and tests. Shared code should consume the configuration rather than fork.

Retain the approved before state, exact action, actor, time, source evidence, target read-back, resulting report effect, and resolved exception record.