Customized payment reporting:
tailored to your accounting needs Automatic translate

The payment gateway provides data in a convenient format, but accounting requires a completely different structure. Amounts vary, dates don’t match, bank fees are spread across lines — and all of this has to be sorted out manually. This is where the finance department’s regular headaches begin.

Discrepancies arise for several reasons. Payment systems record the date a transaction is authorized, while accounting recognizes revenue when funds are actually credited to a bank account. These two events can be separated by several business days, especially when working through payment intermediaries. When hundreds of such transactions occur per month, manual reconciliation becomes a chore, consuming dozens of work hours.

Another problem is the aggregation of standard reports. Most of them show totals for a day or period, rather than details for each payment. For accurate accounting, accounting departments need line-by-line information: the amount before commission, the commission amount, the total credited, the transaction ID, and the payment instrument type.

Before writing the first line of code, it’s worth conducting a short interview with the accountant. A typical list of requirements includes: a breakdown by billing period, a separate line for the acquiring bank’s fee, a payment ID for reconciliation with the bank statement, transaction status (successful, refunded, disputed), and payer type.

For companies working with self-employed individuals, register requirements are expanding. Each payment must be linked to a specific individual, have a confirmed status, and be accompanied by receipt details. Specialized platforms handle these tasks — Consol.Pro , for example, automates the creation of registers of payments to the self-employed, transmits the information to the Federal Tax Service, and allows the finance department to work with already structured data without manual processing.

It’s also worth clarifying the reporting frequency. A daily operating register, a weekly summary, and a monthly closing document are three different products with different levels of detail and different users within the company. Determining the required frequency in advance is easier than redesigning an existing system to meet a sudden need.

Data structure and file formats

Once the requirements have been collected, the output file format can be determined. CSV remains the most universal option — it’s accepted by virtually all accounting systems. However, CSV has its own nuances: column separator (comma or semicolon), encoding (UTF-8 with or without BOM), date format (DD.MM.YYYY or ISO 8601), and number format (period or comma as decimal separator).

If the accounting department uses domestic software, it will likely require Windows-1251 encoding and a semicolon as a delimiter. It’s worth checking this in advance — if the settings don’t match, the import will either fail or the data will be unreadable. For systems that support modern standards, UTF-8 with BOM is a more reliable choice: it eliminates issues with Cyrillic characters across different operating systems.

In addition to CSV, it’s worth considering exporting to xlsx format. Accountants often prefer this format — the file opens with a double-click and displays a formatted table without any additional settings. Generating xlsx on the server side is a solvable task with standard libraries for PHP or Python.

Column headers are a special consideration. During automatic import, they must precisely match the field names expected by the accounting system. Even an extra space or a difference in case can disrupt the field mapping during loading.

Reporting module architecture

A well-designed module is built on several principles. The first is the separation between the data acquisition layer and the formatting layer. Database queries and file construction logic should not be mixed in a single function: such code is difficult to maintain and test in isolation.

The second principle is parameterized filtering. The user specifies a date range, selects the transaction type, and specifies the counterparty or operation status. All parameters are passed as query arguments rather than hard-coded. This allows for new analysis dimensions to be added without rewriting the core logic.

The third principle is asynchronous generation for large-scale exports. If a report covers six months of operations with thousands of rows, generating it synchronously via an HTTP request is poor practice. It’s better to queue the task (via Redis or any message broker), generate the file in the background, and notify the user when it’s ready. This eliminates timeouts and load-related failures.

Caching deserves special attention. Regenerating the same report for a closed period is pointless — the data will no longer change. A cached file with a hash of query parameters allows for instant execution of repeat queries and reduces the load on the database during peak activity at the end of the billing period.

Integration with accounting systems

Manually uploading a file to an accounting program is already a step up from manual data entry. True automation begins when the file is transferred directly via an API or scheduled, without human intervention.

Many corporate accounting systems offer APIs for document import. Setting up automatic register transfers allows you to completely eliminate manual workflow: reports are generated on a schedule — daily, weekly, or on the last day of the period — uploaded to the system, and journal entries are created without the need for an accountant.

For companies not yet ready for API integration, automatic report emailing is a sensible interim solution. The task scheduler generates a file and attaches it to the email, allowing the accountant to receive the completed document without having to access the platform interface.

It’s helpful to provide error notifications. If automatic data transfer fails — a report isn’t generated or the upload to the system is interrupted — the responsible employee should receive an immediate alert. A silent failure discovered three days later creates far more problems than one detected immediately.

Sometimes the accounting department wants to manually initiate the download but only receive the finished file without having to navigate the platform’s interface. In this case, a separate, minimalist dashboard is the solution: select the period and download the file.

Security and access control

Financial data requires a clear access policy. Standard approaches apply here: delineating permissions by role, logging report generation requests, and limiting access periods based on user roles.

It’s unacceptable for a regular manager to be able to download a complete annual payment register with the amounts and IDs of all counterparties. The access matrix determines who can request a report, for what period, and with what detail. This also affects compliance with regulatory requirements for personal data protection.

Logging the downloads themselves is a separate issue. Recording who downloaded a particular report and when is essential for auditing: if a discrepancy in the figures arises, the log will allow for a complete picture without guesswork.

When transferring files over the network, all connections must use encryption. Transferring financial ledgers over unsecured channels is a patchable vulnerability, addressed at the infrastructure level, not the application code.

Quality control at the output

Before presenting a report to the user, the module must check it for internal consistency: the sum of the rows matches the total row, the number of transactions matches the request metadata, and there are no duplicate transaction IDs.

If there are gaps in the database — transactions without a counterparty or with an unknown status — the report should explicitly flag such rows, rather than silently skipping them or entering a zero value. The accountant sees incomplete data and makes a decision independently.

Output validation takes minutes to develop, but saves hours when working with the finished report — especially if an error is discovered after data has been posted to the registers. Automatic validation doesn’t replace auditing, but it eliminates most obvious discrepancies before the file reaches the accountant.