W każdej z tych metod o ewentualnych błędach danych dowiadujemy się dopiero z chwilą uruchomienia akcji, a więc zawsze nie w porę. Z chwilą użycia porcji danych do przetwarzania jest już za późno na jakiekolwiek korekty. Jedynym ratunkiem może być "inteligencja" oprogramowania, którego algorytmy zachowają się w sposób rozsądny i nie dopuszczą do katastrofy w przypadku pojawienia się sytuacji wyjątkowej. A sytuacje te mogą być nie tylko wynikiem złej jakości danych wejściowych, ale także skutkiem błędów w samej logice przetwarzania, która dopiero staje się pierwotną przyczyną generowania niepoprawnych wartości. O ile w systemach preferujących scentralizowany model przetwarzania, transakcja zawierająca błędy zostanie odrzucona, o tyle w systemach o rozproszonym charakterze bywa różnie.

Modyfikacje danych nie zawsze wykonywane są jako spójne transakcje. Często z założenia operacje porcjowane są na logiczne bloki, aby przez programową defragmentację uporać się z niejednorodnością heterogenicznych uwarunkowań struktury przetwarzania. W takim układzie trudno już zadbać o spójność transakcyjną - jeśli gdzieś wystąpią błędy, to tylko część podsystemów zrealizuje swoje zadanie, skutkiem czego informacja zostanie zmieniona tylko w pewnej części całej logicznej sekwencji. Są to działania wysokiego ryzyka, gdyż doprowadzają do rozwarstwienia informacyjnego, a luki wynikłe z tego hazardowego zachowania niezwykle trudno uzupełnić. Generalnie winę ponosi tu architektura systemu nie gwarantująca podstawowej spójności transakcyjnej, co przy dzisiejszej technologii w zasadzie nie powinno mieć miejsca.

Niespójna procedura aktualizacji

Generalnie za jakość danych propagowanych do różnych podsystemów odpowiedzialność biorą stosowne interfejsy, a więc algorytmy przygotowane na określone sytuacje. Bywa jednak, że dane z technicznego punktu widzenia są poprawne, ale z logicznego już nie bardzo, bo algorytm nie jest w stanie do końca zróżnicować tych rodzajów poprawności. Jeśli wskutek niespójności transakcyjnej do jednej bazy przedostała się informacja o zerowym stanie ilościowym jakiegoś produktu, a w drugiej bazie nie wykonano wyzerowania tejże ilości, to każdy z systemów będzie dysponował inną wiedzą.

Jest to niemal szkolny przypadek niespójności transakcji w procedurach aktualizacyjnych. Logika oprogramowania nie kontroluje całości procesu i po wykonaniu aktualizacji w pierwszej bazie, sekwencja programowa nie jest w stanie wykonać aktualizacji w drugiej bazie (na przykład wskutek jej niedostępności) i jednocześnie nie wycofuje wykonanej wcześniej akcji na pierwszej bazie danych. Wystarczy teraz, że jakiś podsystem wykorzysta tę nieprawdziwą informację zezwalając na odjęcie jeszcze pewnej ilości ze znanego mu stanu niezerowego drugiej bazy i prześle odpowiednie zlecenie aktualizujące do pierwszego z podsystemów, gdzie wartość stanu już wcześniej była zerowa. Reprezentowanie wartości ujemnej w samej bazie danych nie musi stanowić problemu, jednak może być twardym orzechem do zgryzienia dla logiki procesów i dalszego przetwarzania takich wartości. Przykład może trywialny, ale w krótki sposób oddaje mechanikę procesu.

Pewne pozazakresowe wartości danych nie muszą stanowić problemu dla struktury służącej ich magazynowaniu, gdyż definicje pól baz danych są z reguły bardzo elastyczne i nieraz nad wyraz pożyteczne, jeśli chodzi o składowanie w nich dosyć szerokiego zakresu wartości. Natomiast te same wartości mogą okazać się zakałą dla przetwarzania, bowiem logika algorytmów bywa znacznie ciaśniej skrojona.