What are recs good for?

The business usage of data matching and reconciliations (or “recs”) are surprisingly varied.

The fundamental of the process is similar to a database join or the tech world’s “diff” command, but commonly with the added human-in-the-loop factor to deal with exceptions. Anomalous items, for whatever reason, need detected, escalated to a team and resolved. Resolution may constitute quite different actions depending on the situation, a selection might be:

  • data changes in upstream systems (ie fixing the problem at source)
  • rerunning synchronisation processes (ie bring systems into alignment)
  • adjusting the rec rules (adding edge cases, reducing noise)
  • simply acknowledging the issue, to be prioritised / manually dealt with

Commonly the rec tool will track the matches and breaks (ie items failing to match). This may also include raising work tickets in an external workflow tool (such as Freshservice, Zendesk or JIRA), or triggering activity via webhooks or a messaging system such as an ESB (enterprise service bus) such as Kafka or equivalent.

In terms of business use-cases that can be addressed via a rec system, there are many:

  • GDPR / privacy enforcement – such as ensuring only live data is referenced across multiple systems (eg removal of personal data of former staff)
  • Data consistency across multiple systems – best-in-class product selection typically causes a grand fragementation of data over time. As businesses adopt SaaS platforms, this is an area that will become increasingly important.
  • Quality assurance – a similar goal, though often for short term processes or platform migrations
  • Business critical feeds – if the impact of a dropped message (corruption, edge cases, link failure, upgrades) is high, recs are often employed to provide assurance there are no unknown failures.
  • System-of-record vs spreadsheets – many platforms have export functions, or even an API to extract data, however the humble spreadsheet is the ubiquitous data tool. Once data has been exported, and often augmented in a spreadsheet, keeping that data up-to-date can be a real challenge.
  • Constraint checking - aka what-should-be-true – tracking aggregate values, a budget level such as total spend per week, for example (with a tolerance/timing allowance, say)

The examples go on, but hopefully this provides some ideas of places the platform can help. The common theme is that of straight-through-processing (or STP), which is that the systems should process the vast majority of system acrtivity, with teams involved only for the exceptional items, normally errors or special-cases that are either not-yet-catered-for or anomalous in some way.

If you’ve any of these challenges, please get in contact - we’d love to help.

(This post first appeared at https://kenhorn.github.io/recs/reconciliation/events/matching/data/2022/03/20/recs-what-are-they-good-for.html)