Н2 = ЛАт / (А-Ро) х 100%

На початок року ЛАт = 515 373,24 + 1 507 194,86 = 2 022 568,10

На кінець року ЛАт = 375 124,62 + 2 386 787,68 = 2 761 912,30

Загальна сума всіх активів на початок 2001 року складає 6 573 406,18, на кінець року 6 475 633,70.

На початок року А = 6 573 406,18 - 1 373 681,68 = 5 199 724,50

На кінець року А = 6 475 633,70 - 1 226 172,02 = 5 249 461,68

Ро - обов'язкові резерви банку - на початок року 880 391,28, на кінець року 597 936,04.

З відомих даних, згідно балансу за 2001 рік (Додаток №7) та згідно Інструкції ПРБ. “Про порядок регулювання діяльності банків та кредитних установ” від 26.06.2002г. рекомендуєме мінімально припутсиме значення Н2-20%.

На початок 01 січня 2001року ліквідність філії ПРАК АПБ в м.Рибниця складала:

Н2=2 022 568,10 / (5 199 724,50-880 391,28) х 100%

Н2= (2 022 568,10 / 4 319 333,22 ) х 100%

Н2 = 0,468259335 х 100%

Н2 = 46,8

Н2=2 761 912,30 / (5 249 461,68-597 936,04) х 100%

Н2= ( 2 761 912,30 / 4 651 525,64 ) х 100%

Н2 = 0,43481822 х 100%

Н2 = 43,5

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

III. Проект організації центру прийому комунальних платежів в філії ПРАК АПБ в м.Рибниця

3.1 Функціонуюча система прийому комунальних платежів

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

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

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

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

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

за які послуги і по яких тарифах мені нарахована оплата;

якщо на всі платежі не вистачає коштів, то як оплатити частину з них по моєму вибору, мінімізувавши при цьому кількість породжуваних паперових документів;

якщо я оплачую послугу, то які гарантії своєчасного і точного надходження платежу до адресата і як, у разі потреби, з мінімальними витратами особистого часу і нервової енергії, переконатися в тому, що платіж отриманий постачальником послуги (без походів у ЖЕК, виснажливого "видзвонювання" довідкових служб і т.д.);

як мінімізувати час оформлення платежу в зручному для мене місці (поруч з будинком, роботою і т.д).

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

державні установи (на користь яких перераховуються податки і штрафи);

організації, що надають послуги населенню (ЖЕК, телефонна компанія, постачальники електроенергії, газу, тепла, вода і т.д.);

торгові організації, що приймають торговий виторг.

Очевидне прагнення одержувача платежу побачити (і якомога раніше) гроші за надані послуги на своєму розрахунковому рахунку.

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

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

Цим пояснюються такі дії постачальників послуг як:

вихід зі складу ЖЭКов з відкриттям окремих розрахункових рахунків у банку;

ведення власних розрахункових книжок зі своїми форматами платіжних документів;

переведення клієнтів на оплату по лічильниках (наприклад, по витраті газу, тепла, води);

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

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

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

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

Іншими словами, банку невигідно, коли замість одного платежу на адресу Жэка з'являється 5-6 платежів в адреси водоканалу, газконторы, тепломережі і т.д. Плата за послуги банку в цих двох випадках буде приблизно однакова, але замість одної операції по прийому платежу в першому випадку, доведеться виконати кілька операцій у другому.

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

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

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

У першому випадку, одержувач платежу робить нарахування оплати, оформляє платіжний документ і який-небудь спосіб (поштою, кур'єром і т.д.) передає його платнику.

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

У бухгалтерії перевіряється звітність і формуються платіжні доручення на адресу одержувачів.

Розглянута технологія реалізовується і при роботі з клієнтами філії ПРАК АПБ у м. Рибниця. Більш досконало можливо розглянути діючу систему прийому комунальних платежів на рис. 3.1.

1 етап : Платники, на підставі отриманої квітанції на оплату сплачують суму за наданий об'єм послуг, згідно тарифів.

2 етап: Касир приймає до оплати квітацію та повертає другу її частину з відмітками про здійснену оплату (дата, № пункту, ПІБ касира, наіменування банку.

1 1 1

2 2 2

3 3 3

4

5 5

Рис. 3.1. Система прийому комунальних платежів в філії ПРАК АПБ в м.Рибниця.

3 етап: В кінці дня касири формують реєстри, на підставі других частин квітанцій та даних, внесених в комп'ютер, які вони зберігають на дискетах.

В бухгалтерію банка передаються такі носії отриманих платежів:

дискета,

реєстри з квітанціями,

віддрукований касовий журнал, в якому зафіксована сума отриманих коштів, згідно за симовлами касового плану,

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

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

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

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

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

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

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

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

3.2 Автоматизація традиційної технології прийому платежів в філії ПРАК АПБ в м.Рибниця

Ефект від автоматизації традиційної технології обмежений її внутрішніми особливостями і для досягнення більш відчутного ефекту необхідно трохи змінити підхід до побудови системи. Для цього учасники повинні виробити і прийняти до виконання деякі спільні угоди. У першу чергу, необхідна єдина, усіма визнана методика ідентифікації платника. Це не просто зробити, принаймні, по двох причинах:

готового ідентифікатора платника, який би усіх улаштував, не існує;

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

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

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

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

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

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

перетворює дані, отримані від комунальних служб, до деякого внутрісистемного формату;

виконує всі необхідні дії по веденню бази платників, їхніх заборгованостях, прийнятих платежах;

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

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

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

методику розрахунків оплати банківських послуг за прийом платежів;

формати даних, у яких одержувач платежів буде передавати банку реквізити своїх платників, щомісячні нарахування по платежах і заборгованості;

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

перелік відомостей, що одержувач платежів хотів би доводити до платника;

вимоги до захисту прийнятої (переданої) інформації.

Функціонування системи являє собою послідовність щомісячних циклів взаємодії учасників ( рис.3.2.)

Кожен цикл складається з наступних етапів:

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

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

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

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

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

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

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

Переваги, які з'являються в результаті впровадження нової технології оплати.

Для платників:

Відпадає необхідність самостійно відслідковувати зміни тарифів і заборгованості по періодичних платежах;

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

Спрощується процедура з'ясування непорозумінь по факту прийому платежів;

Для одержувачів платежів:

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

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

Скорочуються терміни проходження платежу і супровідної його

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

інформації;

Створюються передумови для зменшення об'ємів паперового документообігу і поступового відмовлення від обробки повідомлень про прийнятя платежів внаслідок їхньої заміни електронними реєстрами.

Для банку:

За рахунок підвищення рівня сервісу створюються гарні передумови для збереження своїх клієнтів і придбання нових;

Скорочується об'єм непродуктивної ручної праці, затрачуваної на обробку повідомлень;

Зменшується відсоток помилок, зв'язаних із утратою платежів, перерахуваннями на інші розрахункові рахунки і т.д.

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

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

Однак, для цього необхідні, принаймні, дві речі:

банк повинен розробити механізм обслуговування комунальних рахунків і забезпечити йому відповідну нормативно-правову основу;

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

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

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

Учасники проекту: адміністрація і державні органи (БТИ, паспортний стіл, податкова інспекція і т.п.), постачальники послуг (комунальні служби та інші організації, що надають фізичним особам різні послуги), комерційні банки, вузол зв'язку, пошта.

Архітектура і принцип роботи центра

Є мережа пунктів прийому платежів (ППП) різних банків, вузла зв'язку, пошти (агенти). Абоненти (жителі міста) роблять оплату послуг і одержують інформацію про заборгованість перед постачальниками послуг (про нарахування і платежі - у випадку комунальних служб). ППП при роботі використовують доступ до основного сервера системи. На першому етапі обмін даними організовується один раз у день по модемах, у перспективі організація on-line доступу до даних.

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

Інформацію про абонентів (про заборгованість, прописку, надані пільги і т.д.) можуть діставати всі учасники системи в залежності від наданих доступів.

Ідентифікатором абонента може служити паспорт, але доцільно використовувати ідентифікаційну картку (штрих код) для мінімізації

помилок при прийомі платежів. Також передбачається ведення фіскальних кодів кожного платника податків (як фізичної особи).

Рис. 3.3. Схематичне зображення єдиної комунальної системи

Переваги системи:

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

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

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

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

Реалізація проекту розбита на етапи.

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

Первісне завдання полягає в одержанні Центром Прийому (ЦП) від БТИ списку житлових приміщень (будинків, квартир...). Кожному приміщенню присвоюється унікальний код, що надалі не змінюється. БТИ зобов'язано регулярно давати ЦП інформацію про зміни. У свою чергу, ЦП передає список і зміни в списку Постачальникам послуг (ПУ). Кожний постачальник послуг одержує від ЦП цю інформацію і використовує її у своїх розрахунках нарахувань. До абонентів доводиться інформація про привласнення їм унікального номеру.

II етап - ПУ передають у ЦП інформацію про послуги, що надаються ними. На підставі цієї інформації ЦП формує довідник послуг.

На цьому етапі ПУ самостійно здійснюють облік і нарахування сум за надані ним послуги.

Інформація про заборгованість абонентів за кожний вид послуг періодично (щодня) передається в ЦП (Додаток №3). У свою чергу ЦП передає цю інформацію ППП (Додаток №4). ППП роблять прийом від абонентів сум оплати ( цілком чи частково) і видають квитанцію про прийняті суми по кожному виду послуг із указівкою заборгованості. По закінченню роботи пункту здійснюється передача інформації про платежі в ЦП (дод. №4). ЦП формує зведені проводки по кожному виду послуг кожного клієнта і зараховує на рахунок відповідного ПУ. Також ЦП випускає реєстри платежів і передає їхній ПУ. Одночасно файл із даними про оплату передається ПУ (дод. №3). ЦП підтримує історію платежів абонентів.

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

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

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

В цілому банк здійснює прийом слідуючих платежів:

Газ;

Електроенергія;

Вода та каналізація;

Послуги TV “SHERIF;

Квартплата;

Збір за право торгівлі;

Плата в фонд зайнятості населення;

Плата в пенсійний фонд;

Податок на власність;

За дитячий садок;

За навчання в музичній школі;

Різноманітні платежі в ДАІ;

Та ін.

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

Результати впровадження нової системи занесено в таблицю 3.1.

Таблиця 3.1.

Результати впровадження нової системи

Комісійні за звітний рік по прийому комунальних платежів склали 29,51 тис.руб.

Згідно Закону ПМР “Про податок на об'єм реалізації” від 26 грудня 2001 року для грошово-кредитних установ, зокрема для банків, складає 10 відсотків від оподаткованого прибутку. До оподаткованого прибутку береться загальна сума доходів за мінусом сум, які не підлягають оподаткуванню: відсоткові доходи, відрахування в фонд по можливим втратам по кредитам. Згідно звітності про доходи та витрати за 2001 рік (Додаток №8) до оподаткування належить сума 1 188 580,76 руб. ПМР. Податок на об'єм реалізації складе: 1188580,76х10%=118 858,08.

Кількість населення міста Рибниця складає 70 тис. чоловік. При данній системі обслуговування, приймаючи до уваги те, що кожен мешканець міста не йде платити за комунальні платежі, а сплачують за комунальні послуги представники сімей, та при сучасному рівні життя та низкий народжуваності (чисельність сім'ї в середньому 3 чоловіка), потенційними клієнтами, які обслуговуються в системі прийому комунальних платежів складає тільки 12% населення. Інша частина населення обслуговується в пунктах інших банків. З цього слідує, що кількість клієнтів є можливість збільшити до 30% (приймаючи до уваги те, що за деяку кількість населення розрахунки за комунальні платежі здійснює їхнє підприємство, утримуючи плату із з/плати).