Transaction Lifecycle Explained

Understanding how transactions move through Cake Budget helps you make the most of automation features and troubleshoot issues. This guide walks through the complete lifecycle from bank sync to final categorization.

Overview: The Six Stages

1. Bank Transaction Occurs
   ↓
2. Plaid Syncs to Cake Budget
   ↓
3. Transaction Created/Updated
   ↓
4. Rules Evaluation & Execution
   ↓
5. Funding Schedule Detection
   ↓
6. Final State & Display

Let’s break down each stage.

Stage 1: Bank Transaction Occurs

Where it happens: Your actual bank

You make a purchase, receive a deposit, or a bill auto-pays from your account.

Transaction States at Bank:

• Pending: Transaction authorized but not yet posted (1-3 days typical)
• Posted: Transaction officially cleared and settled
• Reversed: Bank cancels or corrects the transaction

Timing:

• Instant: Card swipe at store
• Hours: ACH transfers
• Days: Checks, wire transfers

Stage 2: Plaid Syncs to Cake Budget

How sync happens:

Real-Time Webhook Sync (Primary)

When a transaction posts at your bank:

1. Bank notifies Plaid of the new transaction
2. Plaid sends webhook to Cake Budget within seconds
3. Cake Budget immediately syncs your account
4. Transaction appears in your app within seconds

Advantages:

• Near-instant updates
• No waiting for scheduled syncs
• Works for all subscription tiers (including trial)

Backup Sync (Safety Net)

A daily sync runs at 3:00 AM as a safety net:

• Catches any missed webhooks
• Only syncs accounts that haven’t synced in 1+ hour
• Ensures data is never more than 1 hour stale

Fully Automatic

No manual intervention needed:

• Syncs happen automatically throughout the day
• Webhooks trigger immediate updates when banks notify Plaid
• Daily backup sync ensures nothing is missed
• You never need to manually refresh

What Gets Synced

Transaction Data:

• Merchant name
• Amount
• Date (authorized and posted dates)
• Transaction ID (unique identifier)
• Category hint from bank
• Pending vs. posted status

Account Data:

• Current balance
• Available balance
• Account name
• Account type

Stage 3: Transaction Created/Updated

In Cake Budget’s database:

New Transactions (Added)

When Plaid reports a new transaction:

1. System checks: Does this transaction already exist? (prevents duplicates)
2. If new: Creates transaction record with all Plaid data
3. Initial Import flag: First 180 days of history marked as “initial import” to suppress email notifications
4. Bank category hint: Stored but not automatically used (rules determine categorization)

Modified Transactions

When Plaid reports a transaction changed:

1. Find existing transaction by Plaid transaction ID
2. Preserve user edits: If you manually edited description, category, or slice—those are kept
3. Update other fields: Amount, date, merchant name updated from Plaid
4. Status changes: Pending → Posted transitions

Example:

Original: Amazon $45.50 (pending)
You edit: Change description to "Office Supplies"
Bank posts: Amazon $45.23 (final posted amount)

Result:
- Amount updated: $45.23
- Your description kept: "Office Supplies"
- Status updated: Posted

Removed Transactions

When Plaid reports a transaction was removed/reversed:

1. Find the transaction in Cake Budget
2. Delete it completely
3. Slice balance restored (if it was assigned to a slice)
4. Balance history updated

Common Reasons for Removals:

• Bank error correction
• Merchant refund/cancellation
• Duplicate charge reversal
• Fraud dispute resolution

Stage 4: Rules Evaluation & Execution

Immediately after transaction creation:

Rule Evaluation Process

1. Fetch all active rules for the user
2. For each rule:
   • Check if conditions match the transaction
   • AND logic: All conditions must match
   • OR logic: Any condition can match
3. If conditions match:
   • Execute all configured actions in order
   • Record which rules were applied
   • Log success or failure

Action Execution

Actions execute sequentially:

Rule: Process Starbucks Purchase
Actions:
1. Assign to Slice: "Dining Out" ← Executes first
2. Assign Category: "Coffee Shops" ← Then this
3. Round Up to Emergency Fund ← Finally this

Common Actions:

• Assign to specific slice (depletes slice balance)
• Set transaction category
• Round up to nearest dollar (sends change to savings)
• Update description or add notes
• Split into multiple parts
• Transfer funds between slices

Multiple Rules Matching

If multiple rules match:

• All rules execute (not just the first)
• Later actions can override earlier ones
• Consolidated email notification sent (not one per rule)

Example:

Transaction: Starbucks $4.50

Rule 1: Merchant "Starbucks" → Assign to "Dining Out"
Rule 2: Amount < $5 → Add note "Small purchase"
Rule 3: All transactions → Round up to Emergency Fund

Result:
✅ Assigned to Dining Out (Rule 1)
✅ Note added (Rule 2)
✅ $0.50 sent to Emergency Fund (Rule 3)

Skip Conditions

Rules don’t run on:

• Internal transfers: Manually moved funds between slices
• Split child transactions: Children of split transactions (respect manual splits)
• System transactions: Recurring slice resets, auto-contributions
• Deleted transactions: Transactions you’ve manually deleted

Stage 5: Funding Schedule Detection

For income transactions:

Detection Check

After rule evaluation, the system checks:

• Is this transaction positive (income/deposit)?
• Does it match any active funding schedule criteria?
  • Keywords match in description?
  • Amount close to expected paycheck?
  • Account matches funding schedule?
  • Date within early/late window?

If Match Found

1. Record the match: Links transaction to funding schedule
2. Create allocations: For each slice in the funding plan:
   • Calculate amount (fixed dollar or percentage)
   • Update slice balance
   • Record the funding event
3. Advance schedule: Calculate next expected paycheck date
4. Send notification: Email confirmation of funding

Example:

Transaction: "PAYROLL DIRECT DEP" $2,500

Funding Schedule matches:
- Keywords: "Payroll" ✓
- Amount: $2,500 ✓
- Account: Checking ✓

Actions:
- Rent slice: +$1,000
- Groceries slice: +$400
- Emergency Fund: +$500
- Safe-to-Spend: +$600 (unallocated remainder)

If No Match

Transaction remains as a normal deposit:

• No automatic slice funding
• Available for manual categorization
• Increases Safe-to-Spend (if not assigned to a slice)

Stage 6: Final State & Display

Transaction reaches stable state:

What You See

In Transaction Tables:

• Merchant name (or description if edited)
• Amount
• Date
• Category (from rules or manual assignment)
• Slice (if assigned)
• Status indicators:
  • Pending badge (if not yet posted)
  • Split indicator (scissors icon with count)
  • Internal transfer marker

In Slice Details:

• Transaction appears in the slice’s transaction table
• Slice balance decreased (for expenses) or increased (for funding)
• Balance history shows the change

In Safe-to-Spend:

• Unassigned transactions increase Safe-to-Spend
• Assigned transactions don’t affect Safe-to-Spend (allocated to slices)

Transaction Properties

Immutable (Can’t Change):

• Transaction ID from Plaid
• Original bank posting date
• Source account

User Editable:

• Description/name
• Category
• Slice assignment
• Notes
• Can be split into multiple parts

System Managed:

• Rules applied history
• Funding schedule matches
• Balance history
• Internal transfer flag

Special Transaction Types

Pending Transactions

What they are: Transactions authorized but not yet posted at the bank.

How Cake Budget handles them:

• Synced from Plaid as soon as authorized
• Marked with “Pending” badge
• Amount may change when posted
• Rules still evaluate and execute
• Balance updates when final amount posts

Lifecycle:

Day 1: Swipe card at store → Pending $50.00
Day 2: Still pending, shows in Cake Budget
Day 3: Posts at bank → Updated to $49.87 (final amount)

Internal Transfers

What they are: Virtual money movements within Cake Budget.

Sources:

• Move Funds feature
• Auto-contributions
• Recurring slice resets
• Funding schedule allocations

Special Behavior:

• Skip rules evaluation (no auto-categorization)
• Skip funding schedule detection (not income)
• Marked with special flag in the system
• No email notifications (you initiated them)

Split Transactions

Parent Transaction:

• Becomes a placeholder after splitting
• Doesn’t appear in main transaction tables
• Maintains link to all child transactions
• Can’t be deleted individually

Child Transactions:

• Appear in transaction tables like normal
• Each can have different slice/category
• Skip rules evaluation (respect manual split assignments)
• Skip funding schedule detection
• Can be unsplit (deletes all children, restores parent)

The Initial Import Process

When you first connect a bank:

What Gets Imported

• Up to 180 days of transaction history
• All transaction types: Purchases, deposits, transfers, fees
• Account balances: Current and available

Special Initial Import Behavior

Email Suppression:

• Transactions from initial import don’t trigger email notifications
• Prevents inbox flood (imagine 500 transactions = 500+ emails!)
• Rules still execute for automatic categorization
• Funding schedules still process income

After Initial Import: New transactions trigger normal email notifications (if you have them enabled).

User Edits & Preservation

What happens when you manually edit a transaction?

Tracked Changes

When you edit:

• Description/name
• Category
• Slice assignment
• Notes

System remembers that you made manual changes.

Future Updates from Bank

If the bank updates the transaction later:

• Bank-controlled fields update: Amount, date, status
• Your edits are preserved: Description, category, slice stay as you set them

Example:

Original from Plaid: "AMZN MKTP US" $45.50
You edit: "Office Supplies - Printer Ink"
Bank corrects amount: $45.23

Final result:
- Amount: $45.23 (updated from bank)
- Description: "Office Supplies - Printer Ink" (your edit preserved)

Troubleshooting the Lifecycle

Transaction Not Appearing

Check:

1. Is it posted at your bank? Pending transactions may not sync immediately
2. Is sync working? Check last sync time in Settings
3. Was it deleted? System prevents re-importing deleted transactions
4. Is the account connected? Verify bank connection is active

Solutions:

• Wait for transaction to post at your bank
• Wait a few hours for next automatic sync
• Reconnect bank if connection is expired

Transaction Not Categorized by Rules

Check:

1. Are rules active? Go to Rules page, verify rule is ON
2. Do conditions actually match? Review the transaction properties vs. rule conditions
3. Is it an internal transfer? Internal transfers skip rules
4. Is it a split child? Split children skip rules

Solutions:

• Manually categorize this transaction
• Update rule conditions to match future similar transactions
• Use backfill to apply corrected rule to past transactions

Balance Didn’t Update

Check:

1. Is transaction assigned to the slice? Unassigned transactions don’t affect slices
2. Is it pending? Some pending transactions may not affect balance until posted
3. Was it removed? Bank reversals restore balance

Solutions:

• Assign transaction to slice
• Wait for posting
• Check balance history for the slice

Related Guides

• How to Connect Your Bank Account - Start of the transaction lifecycle
• How to Create Automation Rules - Control Stage 4 behavior
• How to Setup a Funding Schedule - Automate Stage 5 for paychecks
• Concept: How Rules Automation Works - Deep dive into rule execution
• Concept: How Funding Schedules Work - Deep dive into paycheck detection

---

The Bottom Line: Transactions flow through a sophisticated pipeline designed to categorize automatically, detect income, and keep your budget accurate—all in real-time with minimal manual work required.