Można w tym wypadku przyjąć różne metodologie postępowania, wskazując na przykład a’priori, że zawsze w razie dubletu jako wzorcowe traktowane są dane z faworyzowanego zestawu albo też pozostawić decyzję operatorowi. W przypadku scalania dwóch do tej pory niezależnych systemów: kadrowego i księgowego, z których każdy indywidualnie zawiera dane osobowe pracowników, na pewno jako bardziej miarodajny informacyjnie wzorzec w gestii danych osobowych wybierze się bazę kadrową, zakładając, że tam powinna być aktualniejsza informacja osobowa. Jest to założenie z reguły prawdziwe, chociaż nie do końca w każdej firmie - bywają i takie przedsiębiorstwa, reprezentujące sobą dojrzałość organizacyjną oseska, gdzie dla celów podatkowych pracownica potrafi bez wiedzy działu kadr zgłosić fakt zmiany nazwiska jedynie w systemie księgowym. Zakłada się jednak, że we wszystkich bazach danych data urodzenia tejże pracownicy będzie właściwa, czego z pewnością pieczołowicie dopilnuje sama zainteresowana.

Pytanie, czy tego rodzaju konflikty występujące z racji dublowania się informacji lepiej korygować ręcznie, czy algorytmicznie, pozostaje otwarte. Rozwiązanie musi być dopasowane do skali i różnorodności zagadnienia. W niektórych zastosowaniach dużą stopę błędów konwersji wniosą metody algorytmiczne, a w innych ręczne. W zależności od skali przedsięwzięcia można zastosować różne metody kontroli jakości tego procesu, aby zminimalizować możliwość propagacji istniejących błędów i generowania nowych. Zrozumiałym wydaje się fakt, że przy dużej ilości danych niemożliwe jest sprawdzenie wszystkich wpisów i zakłada się z góry jakiś współczynnik błędu, dotyczący najczęściej klasy danych mniej istotnych, na co w zasadzie każdy użytkownik przystanie, pod warunkiem, że saldo jego konta nie ucierpi na tym zabiegu.

W trakcie konsolidacji danych z różnych systemów ujawniają się ze szczególną ostrością błędy wynikające ze zmiany właściwości opisywanych obiektów. Powodem tego jest to, że przy współistniejącym przed podjęciem procesu konsolidacji braku integracji, zmiany właściwości obiektów były odnotowywane w tych miejscach, gdzie z jakiegoś powodu, na przykład urzędowego, być musiały. Pozostałe zaś miejsca zarosły chwastami dzikiej informacji, która niestety bywa z kolei wykorzystywana do zachwaszczania innych systemów. Przykład braku odnotowania we wszystkich firmowych bazach danych faktu zmiany nazwiska lub adresu jest jak najbardziej typowy.

Błędy w logice

Wiele współczesnych systemów transakcyjnych zorganizowanych jest wielowarstwowo - i to zarówno w sensie technologii przetwarzania, jak i czasu wykonania. Niektóre operacje realizowane są wprost na docelowej bazie danych, inne korzystają z buforów pośredniczących, jedne generują skutki natychmiastowe (w czasie rzeczywistym) inne z kolei działają z celowym opóźnieniem, tworząc bufor transferowy operacji zakwalifikowanych do wykonania.