{"id":157,"date":"2026-11-05T09:00:00","date_gmt":"2026-11-05T08:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=157"},"modified":"2026-11-05T09:00:00","modified_gmt":"2026-11-05T08:00:00","slug":"financiele-boeking-verzendintentie-audit","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/record-the-sending-intent-of-every-financial-posting\/","title":{"rendered":"Record the sending intent of every financial posting"},"content":{"rendered":"

Make every automatic financial posting verifiable by recording the sending intent before the API command. Record the source transaction, posting snapshot and deterministic AFAS reference being submitted. After a crash, accounting can then demonstrate what was intended, what may have been received and why a recovery step did or did not write again.<\/p>\n

A log entry after success is too late<\/h2>\n

Many integrations save an external number only when the provider responds successfully. Yet the most dangerous window lies precisely between sending and that response. If the process stops there, no local completion is known even though AFAS may already have created the posting. A later operator sees only \u201cfailed\u201d and may incorrectly send again.<\/p>\n

An execution register therefore starts before the external write. It contains its own attempt ID, workspace, transaction identity, destination type, stable external reference and immutable business snapshot. Sensitive data is limited to what identification and checking require. The state then becomes confirmed, rejected or uncertain, accompanied by the response or verification evidence.<\/p>\n

Minimum execution register<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n
Field<\/th>\nFunction<\/th>\nCheck<\/th>\n<\/tr>\n<\/thead>\n
Source transaction ID<\/td>\nTrace back to PayPal\/Mollie or another source<\/td>\nUnique within account and workspace<\/td>\n<\/tr>\n
Posting snapshot<\/td>\nProves the submitted contents<\/td>\nImmutable, minimised<\/td>\n<\/tr>\n
AFAS reference<\/td>\nTargeted receipt check<\/td>\nDeterministic and collision-free<\/td>\n<\/tr>\n
Attempt status<\/td>\nStarted, confirmed, rejected or uncertain<\/td>\nValid status transitions<\/td>\n<\/tr>\n
External evidence<\/td>\nConfirms the destination record<\/td>\nCompare identity and core fields<\/td>\n<\/tr>\n
Actor or process<\/td>\nOrigin of execution<\/td>\nAutomatic, employee or recovery action<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The register in Connect<\/a> does not replace accounting. It makes the technical transfer to an AFAS setup approved by accounting demonstrable.<\/p>\n

Fictional example: restart during month-end closing<\/h2>\n

Fictional example: online store Klei & Koper processes transaction KK-P-1904. The integration saves the posting snapshot and reference before sending. The process restarts before the AFAS response is saved locally. The execution register contains one started, uncertain attempt; the ordinary order timeline has no confirmed result yet.<\/p>\n

A recovery process searches specifically for the stable reference and finds an AFAS record with the same verified lines. It saves that evidence and closes the existing attempt as confirmed. At month-end review, accounting sees one source transaction, one intent and one destination record. If the contents differed, the register would show a conflict rather than claim the found record as success. This fictional example shows that audit data is a recovery mechanism, not decorative logging.<\/p>\n

Checks for the financial owner<\/h2>\n