Before connecting data to Acc Flow, who owns the facts?

Define source of truth at field level, not just system level

A sales system may own the order number and item amount; a PMS may own reservation events; the bank provides evidence of cash movement; accounting may own approved account or tax treatment. Avoid calling one application the source of truth for everything when different fields have different authorities.

Create a data contract containing field name, business meaning, source system, owner, edit permission, effective time and behaviour after changes. Review this contract before writing integration code.

Keep source evidence distinct from accounting decisions

A receipt image, statement line, receiving record or PMS transaction is evidence of an event; it is not necessarily an approved accounting record. Automation may extract or propose mappings while preserving the original evidence separately from approved values.

When a reviewer changes an account or tax proposal, retain who changed it, when, why and the previous value. Do not overwrite history so completely that nobody can reconstruct what the source sent and what a person decided later.

Every transaction handoff needs identity that survives retries

Use a stable external transaction ID or controlled composite identity together with source and version/event time. If a request is retried after timeout, the receiver should recognize the same event instead of creating another transaction merely because the message arrived again.

When source data changes, explicitly decide whether the business meaning is update, reversal plus replacement, adjustment or a new version. Avoid delete-and-recreate shortcuts that remove audit history.

Define what happens when two sources disagree

Illustrative example: purchasing names supplier A but the invoice identifies supplier B, or receiving says 10 units while the invoice bills 12. Do not simply pick the newest or API-delivered value. Create an exception with evidence and an accountable decision owner.

Some conflicts can be solved through master-data mapping, some require human review and some must be corrected at source. Put conflict policy in the data contract so the rule is not hidden in code or staff memory.

Acc Flow should receive traceable facts rather than unexplained totals

Linda separates Acc Flow and Vertex applications from ERP implementation and states that modules, permissions, handoffs and service scope are confirmed before onboarding. This supports a bounded approach: each source sends facts it owns with references, then accounting workflow reviews the information required downstream.

Before launch, test normal source records, duplicate delivery, post-approval update, conflicts and replay after failure, with control totals and reconciliation. If the supported handoff is a reviewed file import, describe it as such rather than calling it a real-time API.

References: [1]

Apply it to your business

Good integration starts with authority over facts, not endpoint count. The key questions are who owns each fact, who resolves disagreement and whether the target can trace a number back to its source evidence.