I Am Seeing Duplicate Transactions When Using Bank Rules
by John Laporte, President, RRFMG Technology Services
Duplicate transactions in Restaurant365 most often appear when custom bank rules are created that duplicate functionality already embedded in the platform. Restaurant365 includes out-of-the-box automations designed to correctly process POS activity, generate journal entries through the Daily Sales Summary (DSS), and align bank deposits with existing accounting records. When additional rules are layered on top of these native workflows, duplication can occur.
This issue surfaces frequently around third-party delivery deposits, such as Uber Eats, DoorDash, and Grubhub. These channels create confusion because the accounting treatment differs depending on whether the delivery partner is fully integrated into the POS or operating outside of the POS.
If a third-party delivery partner is not integrated into the POS, bank rules are often required to properly classify deposits, create A/R activity, or post revenue. In these scenarios, bank rules serve a necessary and appropriate role.
However, when a third-party sales channel is integrated into the POS, Restaurant365 already creates the required journal entries automatically. Any third-party channel that results in an Accounts Receivable transaction through the POS and DSS does not require a new bank rule. Creating one in this situation duplicates an existing automation and leads to double posting.
Understanding where Restaurant365’s standard automations end – and where custom bank rules should begin – is critical to preventing duplicate transactions and maintaining clean, accurate financials.
Understanding How R365 Is Designed to Work
Restaurant365 is built with a strong accounting foundation that assumes sales activity should originate from the POS, not the bank feed.
To support this, R365 comes with standard bank rules embedded directly in the software. These rules are not arbitrary – they are designed to:
- Interpret bank activity consistently
- Link bank transactions to POS-generated activity
- Support accurate journal entry creation from the Daily Sales Summary (DSS)
When implemented correctly, R365 uses POS data as the source of truth and leverages bank activity primarily for matching, clearing, and reconciliation, not for creating new revenue or receivable entries.
The Role of the Daily Sales Summary (DSS)
The DSS is one of the most critical components of R365’s accounting workflow. It aggregates POS data and automatically builds journal entries that reflect:
- Gross sales by revenue category
- Taxes collected
- Payment methods (cash, credit card, gift cards, third-party delivery, etc.)
- A/R balances for delivery partners
- Clearing account activity for settlements
When the DSS is properly configured, R365 already knows:
- What Uber Eats sold
- How much Uber Eats owes you
- What portion is fees vs revenue
- Which account should receive the future deposit
Because of this, R365 does not expect bank rules to recreate these transactions.
Why Duplicate Transactions Occur
Duplicate transactions typically occur when bank rules are configured to create transactions that already exist in the system.
Here are the most common causes:
1. Bank Rules Creating New A/R Transactions
If a bank rule is set to:
- “Create Transaction”
- Assign a Customer (e.g., Uber Eats)
- Post to Accounts Receivable
R365 will generate a new A/R receipt every time a matching bank deposit appears – even if the A/R was already created via the DSS.
This results in:
- One A/R entry from POS activity
- A second A/R entry from the bank rule
- A duplicated credit on the books:
2. Standard Bank Rules Plus Custom Rules
R365’s embedded bank rules already understand common POS and payment activity. Problems arise when users add custom rules that overlap with standard logic.
For example:
- A standard rule recognizes POS settlement activity
- A custom rule also fires based on keywords like “Uber” or “Eats”
Both rules may apply to the same transaction, causing duplicate postings.
3. Overly Broad Rule Conditions
Rules that are not tightly scoped – such as those based only on transaction descriptions – can unintentionally fire on multiple settlement types, including:
- Gross sales deposits
- Net settlements
- Adjustments or corrections
Without amount controls, account specificity, or customer matching logic, R365 assumes each instance is a brand-new transaction.
4. Settlement Timing Differences
Third-party delivery partners often:
- Combine multiple days of sales into one deposit
- Net fees, refunds, and chargebacks
- Post deposits days after the sales occur
Meanwhile, POS activity is recorded daily through the DSS.
If bank rules are creating transactions instead of matching to existing balances, the timing difference causes R365 to layer new entries on top of already-recorded receivables.
The Importance of Sales and Payment Type Mapping
One of the most overlooked but critical setup steps in R365 is mapping sales accounts and payment type accounts correctly
This mapping ensures that:
- POS sales flow to the correct revenue accounts
- Payment methods (including third-party delivery) post to the right clearing or A/R accounts
- Deposits know where to apply when they arrive via the bank feed
When mappings are incomplete or incorrect, users often attempt to “fix” the issue with bank rules – unintentionally creating duplication.
Proper mapping eliminates the need for bank rules to create transactions at all.
How Third-Party Delivery Integrations Are Meant to Function
For delivery partners that are fully integrated into the POS, R365 already handles the accounting automatically.
When Uber Eats, DoorDash, or similar platforms are integrated:
- Sales flow from the POS into the DSS
- A/R or clearing balances are created correctly
- Fees are recorded as expenses
- Deposits are expected to clear existing balances, not create new ones
In these scenarios:
No bank rule should be creating revenue, A/R, or sales activity.
The bank feed’s role is simply to:
- Match the deposit
- Clear the receivable or clearing account
- Support reconciliation:
Best Practice: Matching and Clearing, Not Creating
The most reliable approach is:
- Use POS integrations and the DSS to create all sales-related journal entries
- Use bank rules only to:
- Match existing transactions
- Post deposits to clearing accounts
- Avoid rules that create A/R receipts for integrated delivery partners
A simplified flow looks like this:
POS Sales → DSS → A/R or Clearing Account Bank Deposit → Matches and Clears Balance
This ensures:
- No duplicate credits
- Clean reconciliation
- Accurate financial reporting.
How to Diagnose the Issue Quickly
If you are seeing duplicates:
- Open the duplicated transaction
- Check the source
- If it originated from a bank rule, that rule is the cause
- Review all active bank rules
- Look for rules that:
- Create transactions
- Assign delivery customers
- Post to A/R
- Disable the rule and reprocess a test deposit
In most cases, duplication stops immediately.
Final Thoughts
Duplicate transactions in R365 are rarely a system flaw. They are almost always a configuration mismatch between POS-driven accounting and bank rule behavior.
R365 is intentionally designed to:
- Trust the POS
- Build journal entries through the DSS
- Use bank activity for clearing and reconciliation – not transaction creation
When sales mappings, payment types, integrations, and bank rules are aligned, duplicate transactions disappear, and the system performs exactly as intended.
If you are experiencing this issue, it is not a sign that R365 is failing – it is a signal that the workflow needs to be brought back into alignment with best practices
