Ревізія підприємства з АБС

Оскільки ревізор не може, як правило, самостійно оцінити ні склад, ні принципи роботи автоматизованих систем, перевірка підприємства з АБС на початкових стадіях повинна полягати в перевірці основних коштів, а саме - апаратної бази АБС.

Не зайвим при цьому буде знати можливі зловживання з боку досвідчених інженерів, що працюють на підприємстві. Назвемо способи їхнього здійснення.

Спочатку інженер купує на ринку неробочі комплектуючі, які за параметрами збігаються з використовуваними на підприємстві справними. Потім він непомітно підмінює робочий блок на несправний і повідомляє про “раптову” відмову. Після покупки нового робочий блок комп’ютера ним привласнюється. Інженер може також повернути на місце робочий блок, а привласнити новий. Якщо комп’ютерна техніка була на гарантії, то симулюється зрив пломби, “випадкове” влучення усередину комп’ютера металевих предметів, тарганів, - при виявленні таких обставин фірми-гаранти не ремонтують техніку безкоштовно (це розриває гарантію). Запобігання таких дій, що наносять матеріальний збиток підприємству, досягається записом в інвентарних картках серійних номерів комплектуючих і веденням журналу обліку ремонту й модернізації ОТ.

Інший спосіб полягає в тому, що працівник підприємства заздалегідь вступає в змову із продавцем ОТ.

Ще один спосіб грунтується на технічних особливостях різних моделей комп’ютерів. Зовні однакові комп’ютери (не за вигляді, а за основними технічними характеристиками) можуть коштувати по-різному через різні характеристики вузлів, що мають зовні однакові споживчі якості. SCSI, EIDE, ISA, VESA, PCI, EDO, SDRAM, VX, HX, TX, ATX, 14”, 15”, 24х, 32х... - такі приставки до основної назви вузла можуть впливати на його вартість. Наприклад, одна з головних характеристик ПК - оперативна пам’ять через різну швидкість дії (типів EDO, DIMM, SDRAM) коштує по-різному - і це при одній і тій же ємності, наприклад в 128 мегабайт. З’ясувати конфігурацію ЕОМ необхідно й запобігти прихованню облікової інформації на дисках ЕОМ, що перебувають на підприємстві, - як фізичних, так і прихованих логічно - в операційній системі.

Часто в бухгалтерії комп’ютер значиться: і Системний блок - 1 шт. і Монітор - 1 шт. і Клавіатура - 1 шт. і “Мишка” - 1 шт.

Тобто визначити, який саме ПК, взагалі неможливо, а це створює ґрунт для зловживань технічно освіченим персоналом підприємства. Виявити такі порушення можна, лише залучивши експертів з боку, які порівняли б реальні характеристики ПК із зазначеними в гарантійному талоні. Симптом такого зловживання - більш повільна порівняно зі звичайною робота ПК.

Наступний вид зловживання відзначається особливою витонченістю й тому практично не виявляється. Техніка його проведення така. Спочатку працівник симулює відмову техніки (будь-яким способом). Потім за погодженням з вищестоящим службовцем згодою його на ремонт інженер купує на ринку схожий блок, але несправний. Підприємство легально звертається в ремонтний цех або майстерню.

Можуть також використовуватися помилкові профілактичні роботи. Спочатку інженер наполягає на профілактиці техніки. Після одержання згоди він вступає в змову з ремонтною майстернею про майбутній поділ грошей, які майстерня одержить за “профілактику”. Причому звернення підприємства саме в потрібну йому майстерню інженер може стимулювати порівняно низькою ціною за подібні послуги (адже насправді ремонтники взагалі не будуть нічого робити). Потім з отриманих легально грошей майстерня частину віддає інженерові (звичайно, з “чорної” каси), який влаштував “профілактику” ПК підприємства. Цей прийом також характеризується високою скритністю і тому виявити його практично неможливо. Симптомом так зловживання є невиправдано часті профілактики ОТ.

Інженер може штучно сповільнити роботу ПК (змінивши настроювання комп’ютера) через якийсь час після купівлі. Потім він пропонує керівництву модернізувати ОТ через “повільну” її роботу. При згоді керівництва йде легальне звернення до майстерні й легальний “апгрейд”¹⁵. Хитрість полягає в тому, що звичайно при модернізації майстерні забирають собі старі частини¹⁶. У випадку шахрайства інженер не інформує керівництво про більш високу ціну модернізації. У майстерні ж він домовляється таким чином, що платиться повна вартість нових вузлів, списані ж вузли інженер забирає собі. Модифікація цього способу полягає в тому, що можна нові вузли привласнити, а старим - повернути характеристики швидкодії (можна навіть реально збільшити швидкість роботи процесора стосовно його паспортної швидкодії - можливо й таке...) і повернути на підприємство. Створюється ілюзія збільшення продуктивності роботи ПК і досягається маскування зловживання.

Результатом початкової стадії перевірки має стати повне розуміння перевіряючими принципової схеми АБС (дислокація на території підприємства всіх її компонентів), і принципів її роботи (послідовність подій, ієрархія АБС, залежності між компонентами).

Важливим моментом є з’ясування місця користувача з найбільшими правами¹⁷, а також принципова можливість одержати найбільші права з рядового термінала (і ревізора цікавить не службова інструкція, що забороняє це робити, а принципова технічна можливість¹⁸).

Ревізора повинен цікавити також електронний облік внесених змін - у яких файлах зосереджена інформація про час входу й виходу, прізвищ співробітників і т.п.

Для демонстрації складності перевірки деяких АБС наведемо приклад. Нехай працівник підприємства навмисно спотворив облікові дані про який-небудь об’єкт обліку. При цьому він міг пройти на підприємство без фіксування в контрольно-пропускній системі обліку (тобто комп’ютер буде вважати, що в певний день - саме той, на який зафіксовані зміни, зроблені працівником, - працівник був відсутній). Навіть якщо АБС має можливість передбачати блокування такої можливості з наступною дискредитацією пароля працівника й видачу сигналу тривоги (ми, щоправда, сумніваємося в такій передбачливості розроблювачів), то однаково зловмисник може блокувати й ці настроювання, відповідальні за авторизованість доступу. Цим ми прагнемо показати, що якщо в АБС досвідчені програмісти задумали зловживання, то в найкращому разі її чекає втрата частини інформації про облікові об’єкти. У гіршому - руйнування або зашифрування програмної частини АБС, що для ревізорів рівнозначної її загибелі¹⁹.

Проте не слід думати, що ревізорові доведеться зіштовхуватися з такими ситуаціями в повсякденній роботі. Описана ситуація може відбутися в західній великій фірмі, для українських підприємств такої загрози поки що не існує.

Ревізор повинен довідатися про легальність копій бухгалтерських та інших програм, які, як нематеріальні активи, можуть амортизуватися.

Розрізняється авторське право й право власності на матеріальний носій, на якому записана програма. Купуючи авторське право на програмне забезпечення, фірма здобуває нематеріальний актив.

Як тільки підприємство веде облік на ПЕОМ, то необхідно перевірити, як і на яких умовах були отримані ним програми для бухгалтерії.

Нехай існує бухгалтерська програма “1х”. Вона є інструментальним засобом, разом з яким поставляються додатки “Зарплата”, “Склад”, що працюють під її управлінням.

Купивши авторські майнові права на відтворення програми 1х, покупець допускає тиражування її для подальшої реалізації. У цьому випадку НМА враховується на рахунку 04 і підлягає амортизації. При цьому вартість придбання авторських прав віднімається від валових доходів рівними частинами протягом усього строку використання. Ним може бути строк, на який передані авторські права (указується в авторському договорі), передбачуваний строк зміни версії або строк діяльності підприємства, але не більше ніж 10 років.

Купивши авторські майнові права на використання програми 1х, покупець допускає використовувати програму як інструментальний засіб для створення нових програм-до- датків. У цьому випадку нематеріальний актив ураховується так само.

Купивши авторські майнові права на внесення змін у

програму 1х, покупець допускає вносити у вихідні тексти додатків зміни з метою одержання нових версій.

Допускаючи продати авторські майнові права на програму, продавець враховує їх як товар на рахунку 28 “Товари”.

Як видно з наведених правил, неправильне відображення операцій з придбання програмного забезпечення в обліку може призвести до фінансових санкцій, тому що амортизація впливає на оподатковуваний прибуток.

АБС характеризується тим, що здатна автоматично формувати бухгалтерські проводки. Ми маємо на увазі записи, що обов’язково випливають після вже проведених. Наприклад, при нарахуванні зарплати працівникові бухгалтер повинен відбити зобов’язання перед соціальними фондами; при реалізації необхідно відображати зобов’язання по ПДВ; при зміні курсів валют - відображати курсову різницю й т.д. Саме так ці проводки АБС здійснить автоматично - після перерахованих. Тому при перевірці комп’ютеризованої облікової системи ревізорові необхідні дані, що характеризують її настроювання, які відповідають обліковій політиці підприємства: коефіцієнти перерахування валют;

відсоткових ставок, методи оцінки й т.п. Одержавши ці дані, ревізор вибірково перевіряє, чи укладаються вони в загальну картину інформаційних потоків, перелічених ним самостійно.

Після з’ясування фізичної й логічної організації АБС ревізор повинен вибірково перевірити повноту введення в комп’ютер первинних даних, одночасно перевіряючи правильність їхнього введення. Це досягається звіренням обраних ним первинних документів (відповідно до теми перевірки) і відповідних ним електронних документів. Якщо в АБС не організоване зберігання електронних копій первинної документації, то в ній повинні бути тематичні журнали обліку операцій, де первинні дані знаходять своє відбиття обов’язково.

Допустимо, що в силу недосвідченості ревізорів, їх все-таки обдурили, змінивши під час перевірки електронні дані. Але є можливість порівняти офіційну звітність: в електронному виді (зберігається на підприємстві), оригінали звітності, здані в контролюючі органи (зберігаються за місцем здачі).

З появою на вітчизняному ринку потужних дешевих ЕОМ стало можливим оперативно проводити підтверджуючу перевірку, тобто повторення за бухгалтером усіх проводок за період (з виведенням залишків по рахунках). На основі представленій підприємством інформації про систему обліку ревізор спочатку будує математичну модель, використовуючи будь-який програмний пакет²¹. Потім він вносить туди залишки на початок періоду, що перевіряється, обороти за період - і програма може видати залишки на кінець періоду й необхідні показники (співвідношення між обліковими даними) - усе, що може знадобитися ревізорові. При перевірці правильності розрахунку утримань із заробітної плати ревізорові досить ввести у свою електронну таблицю дані відомості й потім, без підрахунку вручну, просто порівняти отримані дані з наявними. Для таких дій можна використати й стаціонарний персональний комп’ютер ревізованого підприємства. Отримана інформація може бути збережена на власні диски ревізорів - для використання в наступних перевірках.

Ми вважаємо, що солідний розробник програм для обліку повинен передбачити в ній можливість відкачки інформації незалежною програмою-ревізором²², що й буде формувати необхідні дані по періодах, облікових об’єктах, грошових потоках та й, з будь-якого питання.

Варто мати на увазі, що іноді при резервному копіюванні й відновленні файлів бувають помилки з останніми датами їхніх редакцій. Тобто не виключений варіант, що бухгалтер, знайшовши й виправивши помилку, вважає, що все в порядку. Потім він, копіюючи файли, помиляється і копіює “стару” неправильну версію файлу поверх виправленої правильної. У результаті помилка зберігається. Також при мережній комп’ютерній основі організації обліку відомі випадки введення (зміни) облікових даних з наступним збереженням файла не поверх вихідного, а у вигляді самостійного файла. Ця помилка рядових бухгалтерів приводить до наступної плутанини при роботі - через декілька варіантів одного й того ж документа. Бухгалтер, викликаючи певний документ, не знає, що комп’ютер завантажує старий файл (тобто існує ще один або більше варіантів цього ж документа), вводить у нього інформацію. У результаті в АБС є кілька файлів, що містять частково правильну, але розрізнену інформацію, яка тяжко сприймається.

Контроль, будучи формально-логічною процедурою, в умовах АБС одержує можливість застосовувати прийоми перевірки в усіх варіантах їхнього поєднання, окремо ж узятий прийом може бути застосований до всіх облікових об’єктів²³, причому в прийнятний термін. Сам устрій облікового програмного забезпечення такий, що облік є формальною послідовністю дій, а облікова програма - це розроблений сценарій заздалегідь відомих бухгалтерові господарських подій. Строго по цим сценарієм введені вихідні дані, й залежності між ними формують показники роботи й звітність підприємства.

Головна формула бухгалтерського обліку полягає в тому, що сума всіх коштів повинна дорівнювати сумі всіх пасивів і вартості власного капіталу, інакше кажучи, кошти з’являються із джерел:

Кошти = Зобов’язання + Власний капітал.

Після розкрадань не вистачає таких коштів, як готівка або інвентар (устаткування). Зникнення коштів обов’язково спричинює фактичне зменшення лівої частини рівності і щоб сховати цей факт, необхідно провести фіктивну операцію. Інакше баланс не зійдеться, і шахрая можуть виявити²⁴.

Будь-якого починання бажані теоретичні передумови, звернемося до теорії бухгалтерського обліку. Як справедливо зауважує у своїх працях Н. І. Попова, “в умовах застосування ЕОМ використовується один носій даних і для оперативно- технічного, і для бухгалтерського обліку. У результаті ... в бухгалтерському обліку підвищується його оперативність”²⁵. Для ревізора ж цей факт означає можливість практично миттєво одержати дані з теми його перевірки²⁶.

Бухгалтер, оперуючи даними облікових реєстрів, одержує необхідні йому показники. Це можуть бути: залишки товарно- матеріальних цінностей, прибуток, податки, заборгованість, величина зарплати. Причому звичайно бухгалтер не ставить своєю метою перевірку різних даних на збіг, хоча статистичні дані показують, що половина часу бухгалтера йде на узгодження між різними ділянками обліку.

До речі, статистика також говорить і про те, що чверть часу бухгалтер витрачає на пошук потрібної інформації. Ревізор же повинен визначити для себе, як бухгалтер шукає цю інформацію. Відмінно знаючи свою облікову систему, бухгалтер навряд чи буде непродуктивно витрачати час для пошуку необхідних документів. Тому знання бухгалтера про свою облікову систему являють для ревізора інтерес (ознайомлення й оцінка організації обліку). З тією ж статистикою, близько 3/4 документообігу становить інформація для внутрішнього користування бухгалтерів. В АБС ця інформація, швидше за все, зберігається на тій самій ЕОМ, що й строгі облікові й звітні дані. Доказової сили ці електронні документи не мають, але становлять оперативний інтерес²⁷.

Ревізор повинен перевіряти дані обліку за певними критеріями. Очевидно, що при паперовому документообігу збір для ревізора всіх документів з прийому й видачі матеріалів на складі за кілька місяців займе, щонайменше, кілька годин. Для оброблення ж цієї інформації може знадобиться додатковий час. При використанні підприємством АБС ця інформація може бути отримана за кілька хвилин, причому з усіма документами, які повинні побічно підтвердити дані по обліку матеріалів (шляхові аркуші вантажних машин на підвезення матеріалів, нараховану зарплату водіям, оплата матеріалів, дані по виробництву продукції й т.д.).

Потоки однорідних господарських подій пов’язані між собою особливостями технології підприємства. Використовуючи зрозумілу їм логіку подій на підприємстві, ревізор може будувати неочевидні логічні ланцюжки й вимагати від бухгалтерії надання даних, які повинні потім складаються в блоки побудованого ним логічного зв’язку²⁸. При цьому ревізор повинен пам’ятати про можливу неповну автоматизацію облікового процесу. Із цього видно, що з частиною даних йому доведеться мати справу на паперових носіях.

Наприклад, при ревізії оплати праці очевидно, що список працівників підприємства є в бухгалтерії. Є він і в відділі кадрів, і в пропускній службі підприємства, і у внутрішньої охорони. На прохідний заводу може стояти автоматизована система пропуску, що фіксує факт і час приходу працівника. Якщо на підприємстві працюють кілька сотень людей, то на взаємну перевірку різних списків може знадобитися багато часу (причому для якісної перевірки потрібно порівняти всі наявні списки²⁹). У нашому випадку ревізор може легко одержати всі списки в електронному вигляді, відсортувати їх за алфавітом і вибірково перевірити збіг фрагментів³⁰.

Очевидно, що подібне дублювання інформації завжди повинен враховувати грамотний ревізор, причому в будь-якій темі перевірки, тим більше що одержання необхідної інформації в АБС займає кілька хвилин.

Наприклад, загальна формула

Майно (кінець року) - Майно (початок року) - - Вилучення + Вкладення = Прибуток

для ревізора має велику цінність тому, що неможливий до прорахунку ним в умовах паперового обліку прибуток починає проглядатися в умовах АБС. Звичайно, на практиці сьогодні в процес реалізації штучно врізані ПДВ, АС тощо, що не належать до реалізації контировки. Однак для грамотного ревізора застосування таких формул можливе.

Кількість облікових об’єктів може бути великою, але ця проблема може бути вирішена шляхом присвоєння кожному обліковому об’єкту, кожній операції й іншої інформації в комп’ютерній обліковій системі ідентифікатора. Задавши критерій пошуку документа (або операції), завжди можна одержати від комп’ютера необхідний вичерпний список необхідних об’єктів.

Ідеальний випадок для перевірки той, при якому ревізор може зняти будь-які дані, тобто дати команду комп’ютеру по будь-якому напрямку перевірки. Наприклад, видати всі операції періоду в розрізі:

і закупівлі сировини, виплати заробітної плати; і нарахування зношування на будь-який об’єкт (групу об’єктів) основних коштів; і продаж продукції - аж до кожного покупця; і отримання грошових коштів (каса, р/рахунки); ^l відрахувань до бюджету.

Для ефективного використання даних ЕОМ ревізор повинен чітко уявляти собі атрибути (його мовою - реквізити) необхідних йому документів. Це потрібно для правильного й чіткого формулювання вимог, пропонованих бухгалтерові. Наприклад, при пошуку необхідних договорів можуть вимагатися характеристики: ^l номер договору; ^l дата укладення; ^l предмет договору;

і об’єм поставки - грошовий чи натуральний; і відділи, посадові особи, які уклали договори; і контрагенти.

3.4.