Invoicing
Part of Accounting technology improvement
Reviewing recurring integration errors with the responsible owner
Prepare evidence for a recurring integration fault, assign technical and finance decisions, and verify that the fix holds.
Review a recurring integration error with the owner of the affected workflow. Bring a source event, its delivery history, the ledger result and earlier occurrences. Agree on the likely cause, the records needing attention and the check that shows whether the fix holds. Clearing an alert alone does not settle the accounting result.
Prepare a pattern for review
Group incidents by observable failure, not by error label alone. Record the source and destination systems, entity, event type, period, first and latest occurrence, source references, destination references where available, and possible financial effect. Distinguish an item that did not arrive from one that arrived with the wrong account or amount.
Bring a representative source record and its matching ledger search result. Include connection status, delivery history or rejection details where the systems provide them. Read those messages against the relevant product's documentation; a failed response does not by itself establish whether an entry was posted.
Ask the owner / Record the decision
- What changed before the pattern began?
- The access, source field, mapping or rule to inspect.
- Did any affected item post?
- Destination references and uncertain attempts.
- Which records and periods are affected?
- The population to review, including earlier entries.
- Who can correct the cause?
- Named system and finance owners.
- What will prove closure?
- A source-to-ledger comparison and a later-cycle check.
Assign technical and finance decisions
The connection owner may be able to renew access or change a mapping. The finance owner decides what the ledger should show and approves corrections.
If GST treatment or a previously approved period is uncertain, refer that decision to the accountant or BAS adviser before altering entries.
An access change, expired connection, new source value or outdated mapping may explain a pattern, but each is a possibility until checked.
MYOB, for example, documents renewal of connected-app access and warns that some apps may not yet appear in its connection view. That page does not establish the state of a particular integration.
Agree on a bounded correction
Record the old configuration, proposed change, effective date and affected population. Where a controlled setting is available, check an ordinary item and an exception against their source references, counts, amounts and ledger records. Before retrying an uncertain item, establish what the earlier attempt created. Follow the approved correction route if an entry already exists.
Give each affected item a state: correctly posted, missing, repeated, incorrectly coded or still under investigation. Keep open items assigned.
A mapping changed for future transfers does not establish that earlier entries were correct.
Close the pattern
At the next expected delivery, compare source and ledger counts and relevant totals, then inspect selected references. Reconcile any related clearing or bank balance under the usual process.
Record the outcome and the next review date. Close the pattern when the technical route and accounting result can both be explained.
