Aydınlatma metni yükleniyor…
In B2B e-commerce, collection does not end when the payment screen returns a “successful” result. An order may be transferred to the ERP, posted to the customer account, covered by available Direct Debit System risk or authorised by a card processor at different times. The commission may be calculated later, and the net amount may reach the bank account on another date. Refunds, cancellations, partial fulfilment, instalments and chargebacks make the record trail more complex.
A reliable reconciliation structure should therefore treat the Direct Debit System—known in Türkiye as DBS—and virtual POS as parts of an end-to-end data process connecting orders, collections, customer accounts and bank movements. The objective is to explain why each record matched, route discrepancies to accountable teams and preserve every intervention in an audit trail.
Where do DBS and virtual POS fit into B2B collection?
DBS enables a principal company to collect receivables from dealers or distributors through a bank. A bank-assigned dealer limit may be used to cover eligible invoices and settle them at maturity under agreed conditions. Akbank’s DBS overview, for example, states that invoice information can be transmitted through online banking, sFTP or web services and that amounts may be blocked against the dealer’s limit before payment to the principal company at maturity. The exact workflow, use of limits and guarantee conditions must always be evaluated under the relevant bank agreement.
A virtual POS allows a B2B customer to pay by card in a single transaction or through instalments. The payment is first authorised and then transferred to the merchant account according to the bank’s or payment service provider’s settlement calendar. The gross sale and the net deposit may differ because of commission, instalment costs, service charges, reserve periods, value dates, refunds or chargebacks.
When both channels are available in the same portal, the customer’s available DBS risk, the order’s payment terms and the amount eligible for card collection must be managed explicitly. Otherwise, one order may trigger two collection attempts, reserve risk incorrectly or leave a customer-account balance that cannot be closed.
A DBS limit and an internal credit limit are not the same data
The total DBS limit describes the facility assigned by the bank for the dealer, while the available limit is the portion remaining after existing blocks and exposures. An ERP credit limit, overdue balance or internal risk class belongs to the company’s commercial policy. These inputs should not be collapsed into one generic “limit” field. Each check needs a named source, timestamp and independent decision rule.
When a portal displays available risk received from the bank, it should also show when the query was completed and whether the result is definitive. If the bank service is unavailable, using an old balance as a confirmed value may create uncontrolled exposure. Holding the order or routing it for authorised review is usually safer.
End-to-end collection and reconciliation flow
Reconciliation should begin with an immutable transaction identifier created at order time, not with the bank statement. The internal order reference should connect the payment attempt, DBS instruction, virtual POS transaction, ERP document and bank movement. Provider references must be retained, but they should not replace the organisation’s own key. This keeps the chain traceable even if a provider changes.
1. Record the order and payment selection
The system records the customer, legal entity, currency, order value, maturity date, payment channel and basket version. For DBS, it links the dealer’s bank and limit enquiry. For virtual POS, it links the terminal, card programme, instalment selection and payment attempt. A unique request key should prevent a page refresh, timeout or retry from becoming a second collection.
2. Separate authorisation from financial settlement
A successful virtual POS authorisation does not mean that funds have reached the bank account. Likewise, acceptance of a DBS instruction does not guarantee the final outcome on its maturity date. The data model should distinguish statuses such as request received, authorised, risk reserved, submitted for collection, settled, refunded and disputed.
3. Transfer records to the ERP under controlled conditions
The payment result must reach the ERP in the same commercial context as its order and invoice. Repeating a transfer after a network failure must not create a duplicate accounting entry. The ERP document number, submission time and acceptance or error response should be retained in the integration log. The customer balance should not be closed before collection becomes final unless the organisation’s documented policy explicitly allows it.
4. Retrieve provider reports and bank movements
Transaction, commission, instalment, settlement and refund data may arrive from the bank or provider through an API, web service or controlled file transfer. Record the source, reporting period, version and retrieval time of every file. If the same report arrives again, ingestion must remain idempotent. If its contents changed, retain the new version and compare it with the previous one.
5. Match, queue exceptions and close
The system should use strong identifiers first and carefully governed secondary rules afterwards. Order numbers, provider transaction IDs and ERP document numbers are strong matching fields. Similar amounts, dates or descriptions should not be treated as conclusive on their own. Exact matches can close automatically; uncertain or conflicting results should enter an exception queue.
Which fields should virtual POS reconciliation match?
Comparing only the gross transaction amount is insufficient. Reconciliation should also verify the transaction currency, terminal, instalment count, commission rate and amount, expected value date, net settlement, refunds and chargeback relationships. Every movement in a provider report should, where possible, be traceable to the original sale.
- Order number and payment-attempt identifier
- Provider transaction, authorisation and reference numbers
- Gross sale amount and currency
- Instalment count, commission and other deductions
- Expected and actual value dates
- Net amount credited to the bank account
- Cancellation and partial or full refund relationships
- Chargeback amount, reason and current status
Türkiye’s regulatory framework for payment services is shaped by Law No. 6493 and its secondary legislation. When assessing authorisation and permitted activities, organisations should refer to the current information published on the Central Bank of the Republic of Türkiye payment services page. A B2B platform should not position itself as a payment service provider. It should integrate records received from its contracted bank or authorised provider with its own order and accounting data.
Refunds and chargebacks are different processes
A refund is initiated by the merchant and linked to the original sale. A chargeback represents the risk that a card transaction will be reversed following a dispute. They should not be closed with the same status code. A partial refund must preserve the remaining collected amount; a chargeback record should separately track the dispute reason, evidence deadline, supporting files and outcome.
A chargeback may arrive weeks after the original order. Rather than silently changing a period already marked as fully reconciled, the system should open an adjustment, show its effect on the customer account and request financial approval when necessary. Deadlines vary by provider, card scheme and contract, so they should be configurable rather than hard-coded.
How should reconciliation differences be classified and managed?
A long list of unmatched records makes root-cause analysis difficult. Define each exception type together with its expected action, accountable role, severity and resolution target. This lets teams separate technical failures from commercial exceptions and prioritise work consistently.
- Missing record: A POS transaction has no corresponding ERP or order-system record.
- Amount difference: The gross amount, commission, refund or net settlement differs from the expected value.
- Date difference: The value date or account credit date deviates from the contractual calendar.
- Status difference: A transaction shown as successful in the portal is cancelled, refunded or disputed by the provider.
- DBS risk difference: The risk used by the portal differs from the bank’s current available limit.
- Duplicate record: One commercial event creates multiple payment or accounting entries.
The rules engine must distinguish an exact match from a suggested match. When a user accepts a suggestion, the system should retain which records were linked and why. Manual closure should require an explanation, while material discrepancies may require a second approval. For a broader view of statement, ERP and customer-account matching, see the account reconciliation software guide.
| Exception type | Control point | First action | Owner |
|---|---|---|---|
| Missing record | Transaction and document number | Query the source again | IT / Operations |
| Amount difference | Gross, commission and net | Verify the contractual rule | Finance |
| Date difference | Expected and actual value date | Check the bank calendar | Finance |
| DBS risk difference | Limit and query time | Retrieve current risk again | Finance / Sales |
| Duplicate record | Request and transaction ID | Quarantine the second record | IT / Finance |
How should permissions, approvals and audit trails be designed?
Giving finance, sales, operations and IT access to the same data does not mean giving them identical permissions. Sales may see the customer and order context while bank-account details remain restricted. Operations may open a refund request, but refunds above a threshold may need a finance manager’s approval. A system administrator may manage integration settings without being allowed to close a financial discrepancy alone.
Approval rules can respond to the amount, payment channel, legal entity, currency and exception type. Rejection, reassessment, delegation and overdue tasks also need explicit behaviour. The principles in Kumsal Agency’s guide to B2B order approval workflows can be adapted to collection decisions.
The audit trail should include previous and new values, the acting user, timestamp, reason and associated approval. Raw integration data must remain distinguishable from corrected business records. Source data should never be invisibly rewritten after ingestion.
Core controls for security and integration architecture
Keeping unnecessary card data outside the B2B platform is a fundamental way to reduce security exposure. Hosted payment pages, tokenisation and stored-card capabilities should be designed through the bank or authorised provider. The PCI Security Standards Council defines PCI DSS as a foundation for technical and operational requirements protecting payment account data. Sensitive cardholder data should not be copied into an ERP or reporting table for reconciliation.
- Apply least privilege to users and service accounts.
- Keep API keys and certificates in secure vaults and rotate them regularly.
- Encrypt transfer channels and validate file integrity and origin.
- Mask personal and financial fields in screens, exports and logs.
- Validate signatures and timestamps and prevent replay attacks on webhooks and service calls.
- Keep card data and access secrets out of error logs.
Integrations should assume temporary interruptions and use controlled queues. Failed calls can be retried safely, but attempts exceeding the configured limit should enter a technical exception queue and notify the responsible team. Monitoring must measure business outcomes as well as service availability: a missing bank file, POS records not accepted by the ERP or a payment absent on its expected value date should generate distinct alerts.
How should custom B2B reconciliation software be planned?
An off-the-shelf connector may move data, but it cannot by itself resolve an organisation’s credit policies, customer-account model, multi-company structure or approval responsibilities. Discovery should map every event from order creation to bank settlement, together with data owners and exception scenarios. The system of record for customers, orders, invoices, collections and accounting entries must be explicitly defined.
A first release can pilot a limited set of banks, terminals and ERP companies. Teams should monitor the risk of false matches as carefully as the automatic closure rate. Once rules have been validated against real transactions, coverage can expand. User acceptance testing should include partial refunds, timeouts, duplicate notifications, missing files, settlement delays and chargebacks—not only successful sales.
Kumsal Agency designs custom B2B e-commerce and web software around actual business processes, user roles, data ownership and integration requirements. ERP, bank/DBS and virtual POS connections can be planned so orders, collections, refunds and customer-account records share a common but fully traceable data structure.
Conclusion: Reconciliation is process design, not a post-payment report
The objective of DBS and virtual POS reconciliation is not merely to make aggregate totals agree. A dependable system should explain the DBS risk used, the card transaction lifecycle, commissions and value dates, the net bank deposit, refunds and chargebacks within the same order chain. Automated matching reduces operational effort, while exception queues, authorised approvals and audit trails preserve control.
To analyse the bank, virtual POS, ERP and order flows in your B2B collection process and plan a custom integration and management structure, contact Kumsal Agency.