Corporate Banking (CorporateBanking)
Connecting a company to real banks: accounts, beneficiaries, payment with separated entry and approval, batch payment and statement matching. An uncertain status is closed only by an inquiry to the bank, not by sending again.
- Domain
- Corporate payments and bank connectivity
- Target customers
- Companies and institutions with high-volume, multi-bank payments
- Main capabilities
- payment with segregation of duties, batch and scheduled payment, deposit matching, reconciliation, liquidity report
Corporate Banking is the layer that connects a company to real banks: management of and connection to bank accounts, payment beneficiaries, the complete payment cycle with segregation of duties between the person who enters a payment and the person who approves it, batch and scheduled payment, receiving and matching bank statements, reconciliation, and liquidity reporting.
The design of this service rests on three simple principles. A successful response from the bank does not mean the money has definitively landed, an expired waiting period does not mean the payment failed, and delivery of a message does not mean it took effect exactly once. The most important design decision follows from these principles: the “uncertain” status is a real payment status, and the only way out of it is an actual inquiry to the bank, never resending. This decision directly prevents real errors of the corporate payments industry, such as a transfer paid twice because of a timeout.
The identity of banks and bank accounts is read from the Treasury service, and this service owns the operational layer: bank connectivity, credentials, payment authorization, and balances obtained by inquiry. This separation keeps bank identity uniform and reliable across all of the platform's services.
Key capabilities
Secure bank connection
The credential of each connection is stored with standard encryption, and no endpoint returns its raw value.
Payment beneficiaries
Registering and managing beneficiaries with validation of the Sheba number (IBAN) and the destination account.
Complete payment cycle
Fourteen defined statuses from draft to successful, failed or uncertain, with the complete history of every status change.
Segregation of duties in approval
The person who enters a payment cannot be the one who approves it. A multi-level approval rule based on amount and bank is defined separately for each company.
Coverage of common transfer methods in Iran
Paya, Satna, Pol, intra-bank transfer, transfer between the company's own accounts, card-to-card and Sheba, each with its own amount limit and acceptance hours.
Management of the uncertain status
Automatic, scheduled inquiry to the bank for payments that received no clear response, in place of blind resending.
Batch and scheduled payment
Batch submission of payments (such as salaries) and scheduling of recurring payments.
Matching of incoming deposits
Reading the bank statement and identifying which invoice or customer each incoming deposit relates to.
Reconciliation
Seven defined discrepancy types (uncertain status, amount difference, transaction not found, duplicate payment, unmatched deposit, balance difference, failed voucher), each with a defined resolution path.
Two-step accounting entry
Money accepted by the bank first sits in an intermediate “funds in transit” account and is moved to the bank's final account only when the statement is confirmed.
Liquidity report
Separation of the account balance from the balance that is actually usable (after deducting commitments in progress), together with a liquidity forecast for the next fourteen days.
Management dashboard
Nine key indicators (such as amount awaiting approval, unknown payments and unallocated deposits) and seven management charts.
Payment by cheque
One of the payment methods, which hands the actual issuance of the cheque to Treasury.
Payment requests from the platform's other services
Other services can request payments, and the same payment engine and the same approval chain run on them.
Business value
Companies that hold several accounts at several banks usually make payments manually and in a scattered way, and in this model the risk of duplicate payment, lost status tracking and a lack of real segregation of duties is high. By explicitly accepting that the bank's response is not always final, this service obtains an actual inquiry for each ambiguous payment instead of guessing. The result is a noticeable reduction in financial errors, complete transparency in the approval of corporate payments, and real-time visibility of liquidity for the finance manager's decisions.
What sets it apart
- The “uncertain” payment status is formally recognized and managed rather than ignored, and this design prevents the common error of paying twice.
- Segregation of entry and approval duties is enforced at the data level, and not only in the user interface.
- A two-step accounting entry that keeps the money in the intermediate account until the bank statement is finally confirmed.
- The identity of banks and bank accounts is read centrally from Treasury, with no parallel, inconsistent data between services.
See this module on demo data
In a demo session we walk through your organization's scenarios on Dara's demo environment and answer your technical and finance teams' questions.