Every AP platform handles bad data one of two ways. Pre-posting validation checks each invoice against your ERP’s own rules while it is still open, so the coder fixes the problem in context. Post-sync cleanup lets the record leave the platform, fails on the ERP side, and returns it as an exception someone has to reopen, diagnose, and resubmit. Both models eventually produce a correct entry. They produce very different close calendars, and very different workloads for the same headcount.
The timing of validation is rarely on an evaluation scorecard. It should be.
Two models for handling bad data
| Pre-posting validation | Post-sync cleanup | |
|---|---|---|
| When the check runs | While the invoice is open, before it leaves the platform | After the record reaches the ERP or the integration layer |
| Who sees the error | The person coding the invoice | Whoever monitors the sync log, often IT or a systems administrator |
| Context available | Full invoice, documents, and approval thread | An error code and a record ID |
| Fix path | Correct the field and continue | Reopen, diagnose, correct, resubmit, reverify |
| Effect at close | Exceptions resolved during the month | Exceptions surface at cutoff |
| Scales with | Configuration effort up front | Headcount and close hours |
This is not a hypothetical distinction. Oracle’s own documentation for importing Payables invoices from a file describes the batch pattern directly: records land in the Payables open interface tables, and you then search for and validate those invoices inside Payables. Microsoft documents a comparable asynchronous path for Dynamics 365 Finance and Operations through its recurring integrations API. In both cases the validation step is real, supported, and downstream of the person who coded the invoice.
The important asymmetry is context. At the moment of coding, the person has the invoice, the PO, the vendor history, and the approver conversation in front of them. Three days later, in a sync log, they have an error code. The same fix costs several times more.
We built Stampli around the left column, and it is worth being direct about what that costs. Enforcing the ERP’s rules means mirroring them first, so implementation carries more configuration than a platform that exports and lets the ERP sort it out. What you buy with that configuration is an exception queue that does not arrive all at once at cutoff.
What pre-posting validation checks
Validation is not a single test. A platform validating against live ERP rules is confirming several things at once.
- Structural validity. The account, entity, and dimension combination exists and is currently active in the ERP.
- Relationship validity. The selected dimension values are permitted for the chosen account, entity, or project. Cross-validation rules and dimension filtering apply.
- Period validity. The posting period is open and the transaction date is allowed.
- Tax validity. The tax code exists, applies to the vendor and jurisdiction, and calculates to a value the ERP accepts.
- Balance validity. Line amounts, allocations, and tax total to the invoice amount.
- Match validity. Invoice lines reconcile to PO or receipt lines within tolerance, which is where PO and invoice matching either holds up or quietly degrades to a total-to-total check.
- Duplicate detection. The invoice number and vendor combination has not already been processed.
A platform can perform some of these and not others. The useful question is not whether a vendor validates, but which of these checks run before the record leaves and which run after. Ask for that list item by item, including from us.
The sync errors that cleanup queues are made of
These are the error classes AP teams encounter across ERPs. Each is preventable at coding time if the platform can see the relevant ERP rule.
- Invalid or missing tax code. The code does not exist, is inactive, or does not apply to that vendor or jurisdiction.
- Undetermined entity or subsidiary. The transaction cannot be assigned to a legal entity, subsidiary, or company.
- Unbalanced transaction. Line amounts, tax, and allocations do not total the invoice amount.
- Missing required dimension. A department, class, location, branch, or financial dimension is required and blank.
- Invalid dimension combination. Each value is individually valid but the combination violates a cross-validation rule.
- Field length or format rejection. A memo, reference, or description exceeds the ERP’s field limit.
- Closed posting period. The period was open when the invoice was coded and closed before it posted.
- Already-processed purchase order. The PO was closed, fully billed, or consumed by another invoice.
- Inactive or duplicate vendor record. The vendor was merged, deactivated, or exists twice.
None of these are exotic. They are the ordinary friction of coding into a structured ERP. The difference between the two models is simply whether your team encounters them one at a time while working invoices, or all at once during close.
What cleanup actually costs
Cleanup is easy to underestimate because it does not appear as a line item. It shows up in three places instead.
The first is rework time. Every returned record requires reopening, rediagnosis, correction, and resubmission, with none of the original context loaded.
The second is close duration. Exceptions that accumulate through the month arrive together at cutoff, which is why teams working to tighten the AP month-end close process usually find that their bottleneck is exception volume rather than invoice volume.
The third is audit surface. A record that posts, gets reversed, and reposts leaves a longer and more confusing trail than a record that posts once. That matters when you are trying to maintain a clean AP audit trail, and it matters more when a correction is made directly in the ERP by someone outside the approval workflow, which quietly undercuts segregation of duties in AP.
That third cost is the one controllers should raise with leadership, because it converts a workflow inconvenience into a control weakness with a name auditors recognize.
Why cleanup volume grows faster than invoice volume
Exception rates do not stay flat as a business gets more complex. They compound, for a structural reason.
Validation failures come from combinations, not from records. Adding an entity does not add one more way to be wrong. It multiplies the entity, account, dimension, and tax permutations a coder can get wrong. Adding a project structure adds a cascade. Adding an acquisition adds a chart of accounts that does not match yours.
A 2% exception rate on 500 invoices a month is ten records: annoying, absorbable. The same rate on 4,000 invoices across twelve entities is a part-time job, and the rate rarely holds steady because the underlying complexity grew too. This is the trajectory behind most requests to add AP headcount, and it is why strong AP internal controls are easier to sustain when errors are prevented rather than corrected.
Across 1,800+ customers running AP inside 2,800+ entities, that permutation math is the single clearest thing separating environments that absorb growth from environments that hire against it. It is also why we treat validation timing as an architecture decision rather than a feature toggle.
Where validation belongs in the workflow
Validation is most useful at the moment of coding and least useful after approval. A check that runs after an invoice is approved but before it posts still catches the error, but it sends the invoice backward through a workflow that has already consumed approver attention.
Two design questions separate platforms here:
- Does the platform validate against live ERP rules, or against a cached copy of them? A cached copy that refreshes nightly will not know about a period you closed this morning.
- Can the coder resolve the exception without leaving the invoice? If resolution requires a different screen, a different system, or a different person, the model is cleanup wearing a validation label.
Our answer to the first is live rather than cached. Coding in Stampli happens against current ERP structure, with the ERP remaining the system of record, so a period closed this morning is closed in the platform this morning. Our answer to the second is that the coder resolves it on the invoice itself, with the document, the PO, and the approval thread in the same place. Stampli AI performs on average 87% of finance work across 2,700+ unique fields, measured across active customer environments in April 2026, and every suggestion is reviewed and approved by a person before anything posts. AI handles the permutations, people handle the judgment, and the audit trail stays intact. Our walkthrough of validation inside the NetSuite integration shows those checks running in a live environment.
Those are the two answers to demand from any vendor, not just from us.
How to test validation timing in a demo
Ask vendors to fail on purpose.
- Code an invoice to a closed period and watch where the error appears.
- Select a dimension combination your ERP rejects and see whether the platform prevents it or accepts it.
- Submit an unbalanced invoice and note whether the block happens before or after approval.
- Ask to see the exception queue from a live customer environment, not a demo tenant.
- Ask who monitors that queue in a typical deployment. If the answer is IT, AP does not own its own errors.
- Ask what is not validated. Any check the vendor cannot confirm should be recorded as not documented and tested in a sandbox before signature.
Run all six against every platform on your shortlist. A vendor confident in its validation model will not mind failing on camera.
Validation timing is the difference between a close that ends on schedule and one that ends when the exception queue empties. Make every vendor show you an error, not just a success path. To watch validation run against your own ERP rules, request a demo and bring the invoices that usually break.
