Reconciliations

A Reconciliation compares information from two DataSources that should describe the same business activity.

The information may come from different systems, use different names or be grouped differently. INTERA maps the related records, applies defined comparison rules and shows where the two sides agree, where they differ and what requires attention.

Reconciliations are read-only. INTERA identifies differences but does not change records in the connected systems.

Typical uses

Reconciliations are not limited to accounting.

One side	Other side	Question
Sales commitments	Delivered services	Was everything promised actually delivered?
Service usage	Billing records	Was all recorded activity billed?
Billing system	Accounting system	Were all invoices transferred correctly?
Customer orders	Production records	Is production aligned with confirmed demand?
Production records	Shipments	Was completed production shipped?
Asset inventory	Monitoring system	Are all expected assets being monitored?
Backup configuration	Backup results	Did every required backup complete successfully?

How a Reconciliation works

Each Reconciliation follows the same basic process:

1. Select the two DataSources to compare.
2. Define the period and records included in the check.
3. Translate or normalise values that use different names or identifiers.
4. Define how records on one side correspond with records on the other.
5. Compare the required fields using defined rules and tolerances.
6. Calculate the result and present the exceptions that need attention.
7. Retain the result so changes can be followed over time.

A Reconciliation can run manually during configuration and automatically on a defined schedule.

DataSources and filters

The left and right sides can come from different Integrations or from different DataSources within the same Integration.

Filters define which records belong in the Reconciliation. They can be used to select:

• a reporting period;
• particular customers, services or departments;
• active or completed transactions;
• specific currencies, regions or categories;
• records that meet another defined condition.

Both sides should represent the same operational scope before they are compared.

Translations and reference tables

Different systems frequently use different identifiers for the same customer, supplier, product, service or status.

For example:

• one system may store a numeric provider ID while another stores the provider name;
• one system may use COMPLETE while another uses CLOSED;
• several product codes may correspond with one accounting category.

Translations and reference tables resolve these differences before matching takes place. This allows the Reconciliation to compare the underlying business meaning instead of requiring identical source values.

Mapping records

Mapping determines which records on the left correspond with records on the right.

Records can be mapped using:

• one field, such as an invoice number;
• several fields, such as customer, service and billing period;
• a translated reference value;
• a calculated expression;
• grouped or summarised values.

Mapping and comparison are separate steps.

Mapping asks: “Do these records describe the same activity?”

Comparison asks: “If they describe the same activity, do their values agree?”

A Reconciliation can support one-to-one, many-to-one and one-to-many relationships where the underlying systems record the same activity at different levels of detail.

Comparison rules

Once related records have been mapped, comparison rules determine what should agree.

A rule can check:

• whether a corresponding record exists;
• whether values are equal;
• whether a difference remains within an allowed tolerance;
• whether totals agree;
• whether dates fall within an acceptable period;
• whether a status has reached the expected state.

Rules can have different weights so that significant differences have more influence on the overall result than minor exceptions.

Reconciliation results

A completed Reconciliation provides a summary of the evaluated records and separates the result into useful exception groups, such as:

• records found on both sides and matching;
• records missing from the left side;
• records missing from the right side;
• mapped records with different values;
• records excluded by the configured rules.

The purpose is not to produce another large report. INTERA shows the overall condition first and then allows the user to inspect the exceptions responsible for it.

Reconciliation score

A Reconciliation can produce a score from 0 to 100.

A score of 100 means that no penalised exceptions were found within the evaluated scope. Lower scores indicate that exceptions were detected, taking account of their number, impact and configured rule weights.

The score provides a quick indication of condition and trend. It does not replace the underlying results. Users can inspect the exceptions and source values that contributed to the score.

Evidence and history

Each exception should make it possible to understand:

• which records were compared;
• how they were mapped;
• which rule failed;
• which source values differed;
• how large the difference was;
• when the Reconciliation was last performed.

INTERA retains Reconciliation results so users can see whether the situation is improving, deteriorating or repeatedly returning.

Corrections remain the responsibility of the connected operational systems. After the source data is corrected, the next Reconciliation run confirms whether the exception has been resolved.

Reconciliations in Role Packages

Role Packages can include predefined Reconciliations for recurring responsibilities such as sales fulfilment, billing control, revenue assurance, payment verification or IT operations.

The package defines:

• the information required from each side;
• the expected mapping;
• the comparison rules;
• default tolerances and weights;
• the way results are presented.

During installation, these requirements are mapped to the company’s actual Integrations, DataSources and fields.

Starting with a Reconciliation

A useful first Reconciliation should answer one specific question using a clearly defined set of records.

For example:

Did every service recorded as active in the billing system appear correctly in accounting for the same customer and period?

Starting with a narrow question makes the result easier to configure, verify and trust. Additional rules and DataSources can be introduced after the first comparison is working reliably.