Automation of non-cash payments

A few months ago, in order to improve the quality and increase the speed of customer service of legal entities (and IP), a nontrivial task appeared - to eliminate the human factor as much as possible and to automate the transfer of funds received by bank transfer to the user's balance.

Cashless payments are the most convenient way to receive payments for an online service (if we consider legal options), since excludes intermediaries in the form of payment systems that take their commission, for example:

• Webmoney Capitaller - 0.8% when transferring funds to a bank account through the Guarantee Agency . Due to the extremely muddy purpose of the payment “By paying for the purchase of securities under the contract ...”, the bank may have questions regarding the source of these funds, so it’s legal to accept Webmoney through processing when Webmoney assumes the functions of an agent to receive payments. For Russia, this is Paymaster and the commission in this case is 2% , but with daily registries and a legal purpose of payment.
• Bank cards (Internet acquiring) - commission from 2% to 3% . In the case of Topvizor, we use Internet acquiring from Tinkoff Bank and the commission for us is 2.5% .
• Paypal - 3.9% + 10 rubles.
• Yandex.Money ( Cash Desk for Business ), QIWI and Robokassa - 5% .

Thus, we get a commission of payment systems from 2 to 5% against non-cash payment - 0% . That is why an extremely important task was to simplify and automate the process of receiving non-cash funds. The task was divided into several stages:

1. Generation of invoices and contract (if necessary).
2. Control of receipt of funds (at least once per hour).
3. Generation of closing documents.

Invoice generation

It is necessary to request from the client the name and TIN of the organization, the current account number, bank BIC, legal and postal address:

• In addition to the BIC number, a name and a correspondent account of the bank are required; they can be automatically obtained via the API BIK Reference Book of the Russian Federation .
• Postal address will be required to know where to send the original documents after receipt of payment.

The data entry form can be:


Invoice is best generated in PDF format . We initially did HTML option, but faced with a lack of understanding from customers. No matter how technologically advanced a company is, ordinary accountants are responsible for handling incoming invoices (most often at an outsourcing), so they need a familiar and convenient format.
')
The approved unified form of the Account for payment for goods and services does not exist. The form can be any, at the discretion of the company. An example of our account is here . The client can be given the opportunity to immediately download the account, or send it by e-mail.

Control of receipt of funds

As it turned out the most difficult stage - a bank with a sane api, servicing legal entities was not found immediately. On the topic, it was possible to find only discussions on banki.ru and ixbt.com , a question on toster.ru and a discussion of the Wishlist on the Alfa-Bank website of ideas .

According to the results of the analysis of all this information, only one bank with an API was found - this is the SB Bank, integration documentation here www.sbank.ru/Page/Details/internetbank/business/integr

Using the GetLatestAdvices function, you can receive data on payments for the current transaction day (we make a request once per hour) and automatically transfer funds to the user's balance. You can complete the whole day’s reconciliation using the DownloadDailyDocuments function, since theoretically, using only GetLatestAdvices, we can see not all payments.

Payment can be identified by TIN, account number or label in the payment purpose.

If the API constantly gives an error and you opened an office not in Moscow or St. Petersburg, then most likely the API will not be deployed for your region, as it was with us (we were the first client using api bank from St. Petersburg). This issue can be resolved with technical support.

A little later, I learned from Alfa-Bank managers (when I closed the account) that they also have something similar - the 1C integration channel , but to use it you need to get agreement.

Generation of closing documents

When a payment is received to the account, we generate PDF closing accounting documents (in our case, this is the Act of the executed services) and together with the original invoice we send it to the mailing address of the client. Everything.

Going to the post office with the implementation of the 3rd item can be avoided altogether if you switch to the EDM (electronic document management). In Russia, this is quite realistic on the basis of the 63-FZ "On electronic signature" , Article 6, paragraph 1:

Information in electronic form, signed by a qualified electronic signature, is recognized as an electronic document equivalent to a document on paper, signed by a handwritten signature, unless the federal laws or regulatory legal acts adopted in accordance with them require that the document be drafted exclusively on paper.

For this, there are already services with the API and the established formats, but this is a topic for a separate article. I will write about the transition to the EDI hot on the heels, as soon as this function will be implemented in our country.