Accounting Software Integration Guides

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.

An unapplied payment is cash received for a customer but not yet linked to an invoice. A customer credit can also remain unapplied. The invoice can still appear unpaid while the customer has a lower net balance; check how each report displays these separate items before comparing them.

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 the source payment with the posted payment: supplier, bills paid, bank account, date and amount. Open the posted record and verify its effect on bill balances and the general ledger. An import-success message is not enough.

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.

Confirm the payer and the intended invoices using payment details or equivalent evidence. Compare the invoice amounts and any documented fees or adjustments with the deposit total. Apply each invoice only up to its open balance and only once within this deposit.

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.

Track the allocated and remaining amount on each bank line or payment. Reject an application that would allocate more than the remaining cash or more than the invoice's open balance, or reuse cash already allocated. One payment may still be split across several invoices.

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 decisions to pause for review 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 checks of the destination reports.

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 approved values with stable crosswalks, preserve hierarchy and inactive status, reject unmapped records, and verify the dimensions on target postings.

Check that the new system accepted the records, the detailed amounts add up, the AR and AP balances agree with the general ledger, and the destination reports show the intended result. Explain and resolve differences before calling balances reconciled. Any remaining individual exception needs the responsible accountant's documented explanation and decision about whether it prevents sign-off.

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, checks of the posted records, 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.

Follow one record from the source system to the posted accounting entry. Compare error logs, settings, field links, filters, permissions and timing before calling the difference a software defect.

Test creating, updating and cancelling records; duplicates; partial payments; credits; write-offs; offline recovery; cutoff dates; account links; rejected records; and the resulting posted accounting entries.

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.

Keep a shared list of skipped records and connector errors, showing the source record ID, first occurrence, retry status, financial effect, person responsible, next action, due date and evidence of resolution.

Read-only retrieves records. A staged change prepares an exact proposed update for review. Write-enabled automation can change the books and needs approval, checks of the posted result and a way to investigate exceptions.

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

Pause affected automated writes, save the original records and errors, update the documented field mapping, recover records from the last verified cutoff and compare all affected records with the resulting entries in the accounting system.

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.

AI can help extract fields, classify records, suggest matches and explain differences. The reconciliation still needs original records, repeatable checks, approval where required and verification of the posted accounting result.

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.

Before releasing a report, check that source data is current, detailed amounts agree with totals, duplicates are excluded, dates and account links are correct, customer or supplier detail agrees with the ledger, and cash differences and other exceptions are explained.

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 documented and approved settings with schema, validation, version, approval, and tests. Shared code should consume the configuration rather than fork.

Keep the approved before-and-after records, exact action, person responsible, time, supporting records and the resulting accounting and report changes. Document how each exception was resolved.