You corrected the profile three weeks ago. The profile shows the correction. The reconciliation does not.
Both records look right when you check them separately, which is exactly how they get checked.
Second of three articles on first-cycle readiness in Oracle Account Reconciliation.
The first covered reconciliations that were never created, or that nobody can reach.
This one covers reconciliations that exist, are visible, and are configured to do something other than what your design document says.
Two mechanisms cause that. Then two assumptions that are commonly wrong about what the design document even means.
Mechanism One: The Snapshot
When a reconciliation is created, it takes a snapshot of the profile and stores it.
The profile can change afterwards. The copy stored with the reconciliation never does.
So a correction made later at profile level does not reach an existing reconciliation. Not on save, not on the next load, not on period open.
This is sensible design. A compliance record that rewrote itself whenever somebody edited a profile would be worthless as evidence.
But during a build phase, when profiles change daily and reconciliations already exist for testing, the two drift apart continuously and nothing announces it.
The practical consequence is about your evidence pack.
A profile export proves what the profile says. It proves nothing about what the reconciliation says. Build your first-cycle evidence only from profile exports and you have tested the wrong object.
Formats and currency buckets cannot be corrected at all.
Attributes that affect the type of reconciliation being performed, including formats and currency bucket configuration, cannot be changed on an existing reconciliation.
Not "changed with difficulty". The reconciliation has to be deleted, the change applied to the profile, and the profile copied to the period again.
Which is a reason to settle format design before you generate a population, not after.
Mechanism Two: The Order of Precedence
Rules sit at three levels.
Global rules apply across the application, format rules are inherited by every profile based on that format, and profile rules apply to one profile. Execution runs global, then profile, then format.
But rules are not the first thing to run.
The auto reconciliation method is evaluated first. Then transaction and comment copy-forward, for the methods that support it. Then rules, in the order copy transactions, set attribute, auto submit and auto approve.
That sequence has a consequence worth quoting directly, because it is the product's own documentation describing the hole:
"If a customer assigns an auto-reconciliation rule to a reconciliation, and the auto-reconciliation succeeds, then any rule tied to the Submit function (such as require reconciliation attachment) would never be invoked."
Read that again if you have built a control around mandatory attachments or prevented submission.
Auto reconciliation does not satisfy those controls. It bypasses them. The reconciliation closes without ever reaching the point where the rule would have been evaluated. The same is true of Prevent Reconciliation Submission, of required attributes and questions, and of the format property requiring zero unexplained difference, which applies only to manual submission.
The design implication is specific.
A control that must hold for every reconciliation cannot live only in a submission-time rule on accounts eligible for auto reconciliation.
Either the account is excluded from auto reconciliation, or the condition is built into the auto reconciliation criteria, or the control is enforced somewhere else entirely.
The test takes ten minutes and is almost never run. Take an account with a mandatory attachment rule, make it satisfy the auto reconciliation criteria, run the load, and see whether it closes with nothing attached. If it does, that control is decorative on that population.
Two Kinds of Mandatory, and Only One Blocks What You Expect
Attributes and questions both have a Required setting. They behave differently.
A Required format attribute prevents preparers submitting and approvers approving until a value is provided. The attachments setting on multi-line text attributes works the same way.
Questions are certification questions answered before submitting.
Here is the part worth testing: with Required selected, users can close a reconciliation without answering their questions. They just cannot submit or approve.
So an unanswered mandatory question does not block saving or closing. It blocks the workflow step.
A preparer can spend an hour on a reconciliation, save it, close it, come back the next morning, and only then find they cannot submit.
Note that attribute-level Required is enforced at manual submit and approve. Which puts it in the same category as everything above, with respect to auto reconciliation.
Assumption One: Variance Analysis Has a Threshold Field
It does not.
Not hidden in an unusual place. There is no Variance Threshold, no Variance Percentage, no Variance Amount, anywhere in profile or format configuration.
The method exists to ensure balance fluctuations are explained when certain thresholds are exceeded, and that phrasing reads like a setting. It is not one. Thresholds in Variance Analysis are built through the rules engine: a scripted calculated attribute that computes the variance percentage, a custom text attribute to hold the explanation, and a rule filtered on that calculation.
The assumption survives because the product does have native numeric threshold fields, close enough to be mistaken for this one:
- Balance Range (Low) and Balance Range (High) drive the Account Analysis within-range auto reconciliation methods.
- Match Balance Threshold (Percent), a whole number between 1 and 100, and Match Balance Threshold (Number) drive the Balance Comparison tolerance methods.
- Maximum Age Limit drives aging violations.
Every one of those is an auto reconciliation or aging control. None is a variance threshold. Borrowing one to stand in for a variance threshold gives you a control that does not do what the control owner believes it does.
One structural point that surfaces late: Variance Analysis uses the same profile and format concepts as everything else and requires its own separate set of profiles. If your profile count looks low and variance analysis is in scope, check that first.
Assumption Two: Risk Rating Drives Something
It drives nothing on its own.
Risk ratings classify profiles and reconciliations by risk level. They can be used to select accounts for reporting, or to make assignment easier. Alongside Account Type, they are reporting attributes, with values defined by administrators for use on dashboards and list views.
No documented behavior attaches to the rating itself. It does not drive reviewer levels, workflow depth, sampling, due dates or auto reconciliation eligibility. It is a label you can filter and write rules against.
So if your control narrative says high-risk accounts get two reviewers, somebody has to have built that. Check that they did.
What to Test
One simple account does not represent a cycle. Sample across methods, risk levels, currencies, organizational units and workflow arrangements. Then open the reconciliation itself rather than the profile, and confirm:
- Preparer, reviewer and backup assignments, and the calculated due dates.
- Format, method, instructions and mandatory questions.
- Currency buckets and default currencies.
- Which rules are inherited from the format, and which are set on the profile.
- Supporting-document requirements, tested against an account that auto-reconciles.
- Variance thresholds, wherever they are actually implemented.
The profile export is the easy half.
It will never catch a stale snapshot, and it will never tell you which of your controls auto reconciliation is quietly stepping over.
Next in this series: the load reported success, and the balances still are not what the reconciliation shows.