We do not replace Logo, Mikro or Netsis (the accounting packages in common use in Türkiye). We build a finance layer that gathers current accounts, banks, cash, cheques and promissory notes, expenses and cash flow alongside your accounting package, and puts collection, payment and approval processes on rules. The record is still kept in accounting; visibility and process run in this layer.
In a company, the answer to the question of where the money is usually does not sit in one place. The current account balance is in the accounting package, but when each customer's payment falls due is in the sales team's head. The cheque portfolio is kept in a separate ledger or in a drawer; which cheque is to be presented for collection and when is left to memory. Bank movements are checked at the end of the day from the online branch, and expense receipts are gathered at the end of the month. The weekly cash table is usually an Excel file prepared by one person, whose formulas break a little more every month. This scattering works at a small scale; it stops working when payment traffic grows and the number of due dates multiplies. The problem is not that the accounts are kept wrongly. The accounting record writes the past correctly, but it does not show the next three weeks.
The most common decision taken at this point is to change the accounting package, and it is usually the wrong one. Logo, Mikro, Netsis and similar packages are systems that have settled over years on the statutory ledger, tax return, e-invoice and e-ledger side, and that are updated as legislation changes. Rewriting that area is both unnecessary and risky; we do not write it and we do not propose a product to take its place. What we build is a financial management layer that runs alongside your existing accounting package. The source record stays in accounting; current account, invoice and bank data are read from there, and the processes the package often does not carry well enough are added on top — due dates, promises to pay, risk limits, expense approval and cash projections. The records produced in this layer are written back to accounting.
The name for this layer in the literature is FMS, the financial management system. A close term, FRM, means financial risk management and describes the measurement and limiting of currency, interest rate, maturity and counterparty risk. In practice the two are intertwined: placing a risk limit on a customer, monitoring open foreign-currency receivables and seeing a maturity mismatch are FRM subjects, but they live on the same screens. We build FMS in its broad sense and add the FRM side only to the extent of the risk the company actually carries. In an exporting company, currency and letter-of-credit tracking makes sense; in a company working only for the domestic market the same screens stay empty and go unused. Narrowing the scope to the risk actually carried is the most useful decision in this work.
Let us write the limits up front. This layer does not do your accountant's job: it does not file tax returns, does not keep statutory ledgers and is not responsible for the tax correctness of an accounting entry. On the e-invoice and e-ledger side, whatever your private integrator or accounting package does today it carries on doing; we connect to those flows, we do not take their place. And no software collects an uncollectable receivable; what the system does is keep the overdue receivable and the promise to pay visible, and take the uncertainty out of who should be calling. When the expectation is set here, the project works. And we always start the work on site: scope is not written before the existing accounting package, the number of banks, the cheque volume and the work done by hand at month-end have been seen in place.
Businesses whose accounting package runs properly and whose books close on time, but where nobody can say clearly what the cash position will be over the next three weeks. What is missing here is not the record but reading the record forward; when due dates, promises to pay and planned payments come together in the same table, the picture becomes clear and the forecast stops depending on one person.
Companies constantly carrying cheques and promissory notes in their portfolio, tracking paper that has been received, endorsed, presented for collection or dishonoured in separate ledgers. At this volume, a single due date missed affects both a collection and the payment due that day. Holding the portfolio in one place and by status is the first gain.
Companies whose receivables are in dollars or euros and whose costs are in Turkish lira, where the exchange difference quietly changes the profit. In these businesses the open currency position, the maturity mismatch and collection delays need to be seen together. A table kept in a single currency always makes the real situation look calmer than it is.
Structures where the same management has several companies, branches or overseas entities. When each company's accounts are kept in a separate package or a separate database, the group's total cash position can only be produced by merging by hand. Inter-company current account movements are also where that merge produces the most errors; this needs to run automatically.
Customer and supplier balances are read from the accounting package; maturity ageing, risk limits and collateral information are added on top. A current account over its limit or past its due date raises a warning at the moment of order entry. The promise to pay is recorded and whether the promise was kept is tracked; who is to be called is therefore tied to a list rather than to memory. The ageing report can be taken separately by customer, by representative and by company.
Bank accounts flow into the system from statements, using standard file formats such as MT940 or the service the bank provides. Incoming movements are matched with open invoices and collection records; those that do not match build up in a separate list and are not lost. Cash movements, transfers between accounts and the end-of-day close are held in the same structure. How much is sitting at which bank is visible on one screen.
Cheques and promissory notes received, issued, endorsed, presented for collection and lodged as collateral are tracked in a single portfolio by status. The due date, debtor, amount and location of each instrument is recorded; a warning is raised as the due date approaches. Dishonoured paper is reflected automatically against the relevant current account and risk limit. The maturity distribution of the portfolio feeds the cash flow table directly.
Open receivables, open payables, cheque and note maturities, loan instalments and planned payments are brought together on a single timeline; weekly and monthly cash projections are produced from it. Assumptions such as collection delay are entered explicitly and can be changed, so an optimistic and a cautious scenario can be placed side by side. Because the table is not prepared by hand, it is up to date every time it is opened.
Employee expenses, advance clearance and supplier payment requests go through a defined approval chain: who approves is determined by amount, expense type and cost centre. A photograph of the document is attached to the request. An approved payment drops into the payment list and turns into a bank instruction; every step is recorded so that it answers the questions of who, when and for how much.
We work two-way with Logo, Mikro, Netsis and similar packages: current account, invoice and bank data are read from there, and the collection, payment and expense records produced in this layer are written back. e-Invoice, e-Archive and e-Ledger flows carry on running through your existing integrator or accounting package; we connect to that flow, we do not take its place.
Receivables and payables are held in the transaction currency and converted to the reporting currency at the TCMB (Central Bank of the Republic of Türkiye) rate; the effect of the exchange difference on profit is shown separately. The open currency position, maturity mismatches and counterparty concentration are monitored. In the literature this heading is known as FRM, financial risk management; its scope is kept narrow, in line with the risk the company actually carries.
Your accounting package, the number of banks, the cheque volume, approval habits and the work done by hand at month-end are mapped in place. Which table is prepared by whom, and from which data, is written down one by one. Scope is set after that map; a finance software proposal given without discovery almost always comes out incomplete.
Reading current account, invoice and bank data from the accounting package is set up; the first task is to match the balances in the system exactly with the balances in accounting. No screen is opened before that reconciliation is achieved. Opening balances and carry-forward records are also decided together at this step. It is usually the dullest but most decisive step of the project; if the numbers do not agree, nobody trusts the system.
Maturity ageing, risk limits, the cheque and note portfolio and the cash projection are opened in turn. After each screen goes live it is run alongside the old method for a while and the results are compared. The first phase usually takes four to eight weeks; the duration varies with the number of banks and companies.
Expense, advance and payment approval chains are defined; limits, delegation and escalation rules are put in writing. We build the approval flow around how people actually work, not around the ideal organisation chart; otherwise everyone finds a way round the flow and the system runs empty. For critical amounts, the second approval always stays with a person.
Reports, permissions and notifications are completed and the system is handed over to the finance team. Where each figure comes from, and how rates and assumptions are updated, is left in writing. After go-live we continue monitoring, fault clearing and update support under an SLA. The source code, the data model and the documentation remain entirely with you on delivery.
No. This layer does not replace your accounting package, it runs alongside it. Statutory ledgers, tax returns and the e-ledger side stay where they are; we read current account, invoice and bank data from there and add processes on top such as due dates, risk limits, promises to pay, expense approval and cash projection. The records produced in this layer are written back to accounting as well. If you receive a proposal that recommends changing your accounting package, ask for the reasoning in detail; in most cases the real need is not a change of package.
No, and that is not our aim. The system does not file tax returns, does not keep statutory ledgers and is not responsible for the tax correctness of an accounting entry. In terms of both legislation and liability, that area belongs to the accountant and to the accounting package. The system's job is to make those records readable by management and to put the financial processes on rules: who is to be called and when, which payment was approved by whom, what the cash position will be in the coming weeks. The two do not replace each other, they feed each other.
In most cases they can. The majority of banks provide standard statement files such as MT940 from their corporate online branch, and some offer a direct service connection. Which method is possible at which bank is confirmed bank by bank during discovery; it would not be right to give a general answer in advance. At a bank with no service connection, a regular and reliable flow can also be set up by file upload, and a daily upload is enough for most companies.
As reliable as what goes into it. For receivables with a known due date, the cheque portfolio, loan instalments and contracted expenses, the forecast is quite accurate. Whether a customer will pay on the due date, on the other hand, is an assumption; the system does not hide that assumption but holds it as a parameter that is entered explicitly and can be changed. That is why we show an optimistic and a cautious scenario together rather than a single figure. We would advise caution towards any approach that promises a precise cash forecast.
It depends on scope, and a firm timescale only emerges after discovery. In practice the first phase — the accounting connection, current account and due-date tracking and the cash projection — can usually be brought live in four to eight weeks in a single-company structure with few banks. In multi-company groups, multi-bank structures and foreign-currency-heavy businesses that period is longer. Rather than setting a broad scope at the outset, we recommend keeping the first phase narrow, seeing the result and then extending it.
A finance layer that works in agreement with your accounting package: current account tracking with maturity ageing and risk limits, a cheque and promissory note portfolio, bank and cash reconciliation, expense and payment approval flows, multi-currency records and a weekly cash projection. Alongside these, a definition document explaining where each figure comes from. The source code, the data model and all the accumulated data belong to you; you are not tied to us in order to carry on.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We move the budget out of Excel files and into a system that is versioned, has a named owner and is compared with actuals automatically. When the month closes, the variance report is not put together by hand; the reason for the variance is recorded, the forecast is updated and the management pack is produced from the same numbers. The goal is not more reports, but seeing where you stand against target in a single figure nobody disputes.
Details →On legacy systems with no API, we build software robots that take over the repetitive steps a person performs on screen. The robot runs under its own user account and on a schedule; when something unexpected happens it does not guess, it stops and hands the job over to a person along with a screenshot.
Details →We build an inventory of your processes, map them as they really are using BPMN 2.0, and define an owner and a measure for each one. We then run them on a process engine (BPMS) and measure cycle time, waiting points and bottlenecks. If a single flow is all you need, we will say that plainly too.
Details →We build the layer beneath the report: data is pulled from source systems by ETL or ELT, modelled across raw, processed and presentation layers, and stored together with its history. Metric definitions are fixed in a single data dictionary, and quality checks catch silent corruption while the data is still being loaded.
Details →We repair the record-keeping in which the same customer has been created three times and the same material sits under two codes. With matching rules, a similarity score and a review queue, duplicate records are deduplicated, a golden record is produced and distributed back to the source systems, and a similar-record warning steps in whenever a new record is created.
Details →We do not build diagnostic imaging software; your existing PACS stays where it is. What we build is the layer that closes the gap between the device worklist, the patient record, the order, the report and sharing: the image is linked to the right patient, pending orders become visible, and the retention and backup status of the archive becomes auditable.
Details →
