SaaS

AI Amazon Reconciliation Assistant — Beginner Build Guide

A complete beginner-friendly, step-by-step guide to building the MVP, adding AI safely, connecting Amazon and accounting platforms, and deploying the system.

AI Builder Blueprint #2

AI Amazon Reconciliation Assistant

A complete beginner-friendly, step-by-step guide to building the MVP, adding AI safely, connecting Amazon and accounting platforms, and deploying the system.

Prepared by: Imtiaz Ahmad

LinkedIn: www.linkedin.com/in/imtiazahmad004

How to Use This Guide
1. What You Are Building
2. Accounts and Tools
3. Recommended Architecture
4. Build the MVP First
5. Create the Repository and Project Structure
6. Database Design
7. CSV Import and Normalization
8. Fee Classification: Rules First, AI Second
9. Build the Reconciliation Engine
10. Bank Data: Start with CSV
11. Human Review Queue
12. Amazon SP-API Integration
13. QuickBooks Online Integration
14. Xero Integration
15. Dashboard
16. Background Processing
17. Alerts
18. Security and Compliance
19. Testing Plan
20. Deployment
21. Environment Variables
22. Cost Planning
23. Common Mistakes
24. Recovery Prompts
25. Launch Checklist
Official References

How to Use This Guide

This is a follow-along beginner blueprint. Build one phase at a time. Do not ask an AI coding assistant to build the entire SaaS in one prompt. Complete a phase, test it, commit it to GitHub, and only then continue.

Important: This system assists reconciliation; it does not replace an accountant, tax adviser, or the seller’s responsibility to review financial records.

Beginner path: Start with manual CSV imports before Amazon OAuth and bank APIs.
Production path: Add SP-API, accounting integrations, encryption, audit logs, and background jobs after the MVP works.
Safe development: Use sandbox or test companies for QuickBooks and Xero. Never test journal posting in live books first.

1. What You Are Building

You will build an AI-powered Amazon reconciliation assistant that can:

Import

Bring Amazon settlement and financial-event data into your own database.

Classify

Map Amazon fees, refunds, promotions and adjustments to accounting categories.

Reconcile

Compare expected Amazon payouts with actual bank deposits.

Post

Prepare or push clean journal entries to QuickBooks Online or Xero.

Explain

Show issues, confidence scores, trends and SKU-level profitability.

Alert

Notify users about mismatches, unknown fees and unusual refund or reserve activity.

Final workflow

Amazon SP-API / CSV → Raw Data Store → Fee Rules → AI Review → Reconciliation → Human Approval → QuickBooks/Xero → Dashboard & Alerts

2. Accounts and Tools

Create only the accounts needed for the phase you are working on.

| Tool | Why you need it | Official site |

| --- | --- | --- |

| Google AI Studio | Prototype prompts and obtain a Gemini API key. | ai.google.dev/aistudio |

| GitHub | Store code and create safe checkpoints. | github.com |

| Neon | Managed PostgreSQL database. | neon.tech |

| Upstash | Managed Redis for caching and lightweight queues. | upstash.com |

| Vercel | Deploy the Next.js frontend. | vercel.com |

| Render | Deploy FastAPI and background workers. | render.com |

| Amazon SP-API | Retrieve authorized seller financial information. | Amazon Finances API |

| QuickBooks Developer | OAuth, sandbox company and Accounting API. | developer.intuit.com |

| Xero Developer | OAuth, demo company and Accounting API. | developer.xero.com |

| Email provider | Send alerts. Use Resend, SendGrid or another transactional provider. | resend.com |

Do not begin with all integrations. First build CSV import, rules, reconciliation, dashboard and review queue. External OAuth integrations come later.

3. Recommended Architecture

| Layer | Recommended technology | Responsibility |

| --- | --- | --- |

| Frontend | Next.js + React + Tailwind | Dashboard, uploads, review queue, settings and reports. |

| Backend | FastAPI | Authentication, APIs, reconciliation logic and integrations. |

| Database | PostgreSQL | Users, raw imports, normalized events, classifications and audit logs. |

| Cache | Redis | Repeated fee mappings, idempotency locks and job status. |

| Worker | Celery/RQ for Python, or BullMQ only if you add a Node worker | Scheduled imports, classification, reconciliation and alerts. |

| AI | Gemini, OpenAI or Anthropic | Only ambiguous classification and explanations—not arithmetic. |

Architecture correction: Because the backend is FastAPI/Python, Celery or RQ is simpler than BullMQ. BullMQ is excellent, but it normally belongs in a Node.js worker service.

4. Build the MVP First

The first version should not require Amazon, Plaid, QuickBooks or Xero approval.

Create the dashboard shell.
Upload an Amazon settlement CSV.
Store the original file and raw rows.
Normalize rows into financial events.
Classify known fees with deterministic rules.
Send only unknown labels to AI.
Upload a bank CSV and match the deposit.
Show the reconciliation result and review queue.
Export a journal-entry CSV for an accountant.

Copy-paste prompt — project plan

You are a senior SaaS architect. I am building an Amazon reconciliation assistant for beginners.

Create a phased implementation plan, but do not write code yet.
Stack: Next.js frontend, FastAPI backend, PostgreSQL, Redis, Python background worker.
MVP inputs: Amazon settlement CSV and bank CSV.
MVP outputs: normalized financial events, fee classifications, payout reconciliation, human review queue, dashboard and journal-entry CSV export.

Rules:
1. Separate the work into small phases.
2. Define acceptance criteria for every phase.
3. Keep Amazon SP-API, QuickBooks and Xero integrations for later phases.
4. Use deterministic accounting rules before AI.
5. Never allow AI to perform arithmetic or post journal entries without validation.
6. Include security, idempotency and audit logging requirements.
Return the plan only.

5. Create the Repository and Project Structure

amazon-reconciliation-assistant/
├── frontend/                 # Next.js application
├── backend/                  # FastAPI application
│   ├── app/
│   │   ├── api/
│   │   ├── core/
│   │   ├── models/
│   │   ├── schemas/
│   │   ├── services/
│   │   ├── integrations/
│   │   ├── workers/
│   │   └── tests/
├── docs/
├── sample-data/
├── .env.example
└── README.md

Copy-paste prompt — create the skeleton

Create the project skeleton for an Amazon reconciliation SaaS.

Use:
- frontend: Next.js, TypeScript, Tailwind
- backend: FastAPI, Python 3.12, SQLAlchemy 2 async, Alembic, Pydantic v2
- database: PostgreSQL
- cache: Redis

Create only the folder structure, configuration files, health endpoints and local run instructions.
Do not build Amazon, AI or accounting integrations yet.
Add .env.example files with placeholder names only.
Add a README with exact commands for Windows PowerShell and macOS/Linux.
After creating the files, list every file and explain its purpose.

6. Database Design

Store raw data before transforming it. This lets you reprocess historical imports after improving your mapping rules.

| Table | Purpose |

| --- | --- |

| users | Application users and roles. |

| organizations | Seller businesses; supports multi-tenant SaaS. |

| marketplace\_connections | Encrypted connection metadata for Amazon and accounting systems. |

| source\_files | Uploaded CSV metadata, checksum and processing status. |

| raw\_financial\_records | Original row payloads without destructive edits. |

| financial\_events | Normalized sales, fees, refunds, reserves and adjustments. |

| fee\_mappings | Deterministic mapping from source labels to account categories. |

| ai\_classifications | AI suggestion, confidence, prompt version and model metadata. |

| settlements | Settlement period, expected payout and status. |

| bank\_transactions | Imported or connected bank deposits. |

| reconciliation\_matches | Settlement-to-bank matching result. |

| reconciliation\_issues | Mismatches and unresolved explanations. |

| journal\_batches | Proposed accounting entries and approval state. |

| journal\_lines | Debit/credit lines. |

| alerts | User notifications. |

| audit\_logs | Who changed what and when. |

Non-negotiable database rules

Every business-owned row must include organization_id.
Use unique checksums to prevent duplicate files.
Use external IDs and unique constraints to prevent duplicate events.
Financial amounts should use fixed decimal types, never floating point.
Never delete audit records through normal user actions.

Copy-paste prompt — database schema

Design the PostgreSQL schema for the Amazon reconciliation SaaS described below.

Required tables: users, organizations, organization_members, marketplace_connections, source_files, raw_financial_records, financial_events, fee_mappings, ai_classifications, settlements, bank_transactions, reconciliation_matches, reconciliation_issues, journal_batches, journal_lines, alerts and audit_logs.

Requirements:
- multi-tenant organization_id isolation
- UUID primary keys
- NUMERIC for money
- UTC timestamps
- encrypted-secret references, never plaintext tokens
- unique constraints for idempotency
- soft deletion only where appropriate
- indexes for settlement date, marketplace, ASIN/SKU and status
- balanced journal validation

Return:
1. Entity relationship explanation.
2. SQLAlchemy 2 async models.
3. Alembic migration.
4. Pydantic schemas.
5. Tests for constraints.
Do not create API routes yet.

7. CSV Import and Normalization

Amazon report layouts can differ. Build a configurable importer instead of hard-coding one exact column order.

Upload the file.
Calculate a SHA-256 checksum.
Reject an exact duplicate unless the user explicitly reprocesses it.
Detect headers and report type.
Store each original row as JSON.
Normalize dates, currency, marketplace, SKU, ASIN, event type and amount.
Record rejected rows with a clear error.

Copy-paste prompt — CSV importer

Build only the settlement CSV import phase.

Backend requirements:
- FastAPI multipart upload endpoint
- maximum file size configuration
- CSV type and encoding validation
- SHA-256 duplicate detection
- raw file metadata storage
- raw row JSON storage
- configurable header aliases
- normalization into financial_events
- NUMERIC money values
- per-row error reporting
- idempotent reprocessing

Frontend requirements:
- drag-and-drop upload
- progress and processing status
- import summary: accepted, rejected, duplicates
- downloadable error CSV

Add unit tests with synthetic sample files. Do not add AI yet.

8. Fee Classification: Rules First, AI Second

Do not send every row to an LLM. Most labels repeat and should be mapped by rules.

Classification order

Exact seller-approved mapping.
Normalized alias mapping.
Rule or keyword mapping.
AI suggestion for unknown/ambiguous rows.
Human review when confidence is low.

Example structured result

{
  "category": "amazon_referral_fee",
  "account_code": "6100",
  "tax_treatment": "review_required",
  "confidence": 0.91,
  "reason": "Description indicates a marketplace referral commission"
}

Tax safety: Do not let a general-purpose model independently decide whether a transaction is taxable. Tax treatment should be configured by marketplace, entity and accountant-approved rules.Copy-paste prompt — AI classifier

Build the fee-classification service only.

Rules:
1. Apply deterministic approved mappings first.
2. Normalize whitespace, punctuation and case.
3. Use AI only when no approved mapping exists.
4. Require strict JSON output validated by Pydantic.
5. Store model name, prompt version, confidence and reason.
6. Cache by organization + marketplace + normalized label + context signature.
7. Route confidence below 0.85 to human review.
8. AI must never calculate totals or post accounting entries.
9. Do not infer tax treatment; return review_required unless an approved rule exists.
10. Include retry limits and a no-AI fallback.

Add tests for malformed JSON, low confidence, cached results and human override precedence.

9. Build the Reconciliation Engine

The engine should be deterministic. AI may explain a difference, but the balance calculation must be normal application code.

Core calculation

Opening balance + Sales + Credits − Fees − Refunds − Reserves ± Adjustments = Expected payout

The exact components depend on the report and marketplace. Preserve source-level detail and display the calculation used.

Matching strategy

Match currency first.
Use expected payout date windows rather than exact date only.
Compare amount within a configurable tolerance.
Support one settlement to one deposit, many settlements to one deposit, and partial deposits.
Never auto-resolve a mismatch only because an AI explanation sounds plausible.

Copy-paste prompt — reconciliation service

Build a deterministic reconciliation engine.

Inputs:
- normalized settlement financial events
- settlement opening/closing balances where available
- bank transactions imported by CSV

Outputs:
- expected payout
- matched bank transaction(s)
- difference
- reconciliation status
- issue codes and human-readable explanation

Requirements:
- Decimal arithmetic only
- configurable tolerance by currency
- date-window matching
- one-to-one, many-to-one and partial matching support
- idempotent reruns
- no AI arithmetic
- full calculation trace
- manual match/unmatch with audit log
- tests for refunds, reserves, currency rounding, duplicate deposits and partial payouts.

10. Bank Data: Start with CSV

For the beginner MVP, use a bank CSV. Open-banking providers require region coverage, compliance review and user consent.

Create mapping templates for common bank exports.
Require date, description, amount and currency.
Allow the user to preview mappings before import.
Store original rows and prevent duplicates.

Later, add a bank-data provider behind an adapter interface:

BankProvider
├── CsvBankProvider
├── PlaidBankProvider
└── FutureRegionalProvider

11. Human Review Queue

The review queue is the safety layer of the product.

| Review item | User action |

| --- | --- |

| Unknown fee | Approve suggested category or choose another mapping. |

| Low-confidence classification | Approve, edit or create a reusable rule. |

| Unmatched payout | Select bank transaction, split match or leave unresolved. |

| Closed accounting period | Send to accountant; never auto-post. |

| Unbalanced journal | Block export and show the difference. |

Copy-paste prompt — review UI

Build the human review queue.

Create Next.js pages for:
- unknown fee classifications
- low-confidence AI suggestions
- unmatched settlements
- journal batches awaiting approval

Each row must show source evidence, suggested action, confidence, status and audit history.
Actions: approve, correct, create reusable rule, assign, add note and defer.
Require confirmation before bulk approval.
Do not allow users to edit raw imported data.
Use optimistic UI only where rollback is safe.
Add role checks for owner, finance_manager, accountant and viewer.

12. Amazon SP-API Integration

After the CSV MVP works, connect authorized seller accounts. Amazon’s Finances API provides seller-relevant financial information and supports retrieving financial events and event groups. Use the current official version and documentation when implementing; do not rely on a copied endpoint from an old post.

Implementation flow

Create/register the SP-API application and required roles.
Implement seller authorization.
Store refresh-token secrets encrypted or in a secret manager.
Fetch financial event groups and related transactions/events.
Handle pagination and documented delays.
Store the raw response before normalization.
Use external IDs and idempotency constraints.
Respect rate limits and retry with backoff.

Scope: SP-API access is for authorized seller data. It is not a general marketplace competitor-data API.Copy-paste prompt — SP-API integration design

Design the Amazon SP-API integration for the existing FastAPI application.

Use current official Amazon documentation. Do not guess endpoint versions or permissions.

Deliver only:
1. Authorization flow and callback design.
2. Secret-storage design.
3. Finances data ingestion service.
4. Pagination, throttling, retry and idempotency strategy.
5. Raw-response storage and normalization boundary.
6. Connection health and token-revocation handling.
7. Sandbox/mock testing strategy.

Do not change reconciliation logic. Keep Amazon behind a MarketplaceFinanceProvider adapter.

13. QuickBooks Online Integration

QuickBooks Online uses OAuth 2.0. Use its sandbox company first.

Safe flow

User connects their QuickBooks company.
Import the Chart of Accounts.
User maps internal categories to QuickBooks accounts.
Create a proposed journal batch.
Validate total debits equal total credits.
Require approval.
Post with an idempotency/reference key.
Store the external journal ID and response.

Copy-paste prompt — QuickBooks adapter

Build a QuickBooks Online accounting adapter using the official OAuth 2.0 and Accounting API documentation.

Requirements:
- sandbox first
- encrypted refresh token storage
- token refresh and disconnect handling
- import Chart of Accounts
- save user mappings from internal categories to account IDs
- create journal entries only from approved balanced journal batches
- prevent duplicate posting
- store external IDs and API responses
- detect closed-period or permission errors and return to review
- integration tests using mocks plus a manual sandbox checklist

Implement the AccountingProvider interface so Xero can be added later.

14. Xero Integration

Xero also uses OAuth 2.0 and requires an authorized tenant/organisation context for API calls. Use the Xero demo company while developing.

Copy-paste prompt — Xero adapter

Implement Xero as a second AccountingProvider adapter.

Use current official Xero OAuth 2.0 and Accounting API documentation.
Requirements:
- demo company first
- access token, refresh token and tenant ID handling
- retrieve Chart of Accounts
- save account mappings
- post only approved balanced journal batches
- duplicate protection
- store Xero identifiers and full audit metadata
- actionable errors for expired authorization, missing scopes, locked periods and invalid account mappings

Do not duplicate business logic from the QuickBooks adapter. Shared logic belongs in the accounting service layer.

15. Dashboard

The dashboard should help users make decisions, not merely display imported rows.

Settlement status

Reconciled, mismatch, awaiting deposit, review required.

Fee breakdown

Referral, FBA, storage, promotions, refunds, adjustments and reserves.

SKU / ASIN P&L

Revenue, allocated fees, refunds and contribution margin.

Exceptions

Unmatched payouts, new fee labels and unusual changes.

Accounting limitation: A settlement report may not contain every cost needed for a complete product P&L. Product cost, inbound freight, VAT/sales tax, advertising and overhead may need separate data sources. Label dashboard metrics accurately.Copy-paste prompt — dashboard

Build the reconciliation dashboard using the existing API only.

Pages:
1. Overview
2. Settlements
3. Reconciliation issues
4. Fee mappings
5. SKU/ASIN profitability
6. Journal batches
7. Connections
8. Audit log

Add date, marketplace, currency, status, SKU and ASIN filters.
Every KPI must have a tooltip explaining its calculation and data limitations.
Provide CSV export based on the active filters.
Create loading, empty and error states.
Do not invent sample numbers in production mode.

16. Background Processing

Run imports and reconciliation without waiting for a user to open the dashboard.

Suggested jobs

sync_amazon_finances
normalize_financial_events
classify_unknown_fees
reconcile_settlements
prepare_journal_batches
send_alerts

Job safety

Each job needs an idempotency key.
Use limited retries with exponential backoff.
Move permanently failed jobs to a dead-letter/review state.
Do not retry accounting posts blindly.
Expose job health in the owner dashboard.

Copy-paste prompt — worker

Add Python background processing to the FastAPI project using Celery or RQ with Redis.

Create scheduled jobs for finance sync, normalization, classification, reconciliation and alerts.
Requirements:
- idempotency keys
- distributed locks
- retry policy by error type
- dead-letter state
- job run records in PostgreSQL
- structured logs with correlation IDs
- no blind retry for external journal posting
- admin job-health endpoint
- local development instructions

Do not add BullMQ unless creating a separate Node.js worker service.

17. Alerts

Start with email. Add Slack only when customers request it.

Reconciliation difference exceeds user threshold.
Unknown fee type appears.
Refund rate changes sharply.
Reserve amount changes unexpectedly.
Connection or scheduled sync fails repeatedly.
Journal batch remains unapproved.

Avoid hard-coding universal thresholds such as 5%. Let users configure thresholds by marketplace and business.

18. Security and Compliance

Encrypt OAuth refresh tokens and sensitive connection data.
Never expose provider secrets to the browser.
Use organization-level row isolation and role-based access.
Log approvals, mapping changes, journal posting and manual matches.
Use signed upload URLs or strict file validation.
Redact sensitive values from logs.
Support connection revocation and account deletion workflows.
Define retention rules for imported bank data.
Back up PostgreSQL and test restoration.

Copy-paste prompt — security audit

Perform a security review of this multi-tenant financial SaaS.
Do not change code yet.

Review:
- authentication and authorization
- tenant isolation
- OAuth secret storage
- file uploads
- API validation
- Redis exposure
- background jobs
- audit logging
- sensitive logs
- CSV formula injection
- SSRF and webhook security
- journal posting permissions
- deletion and retention

Return findings by severity, evidence, impact, recommended fix and test. Separate confirmed issues from assumptions.

19. Testing Plan

Minimum test cases

Same CSV uploaded twice.
Same Amazon event returned twice.
Refund posted after the original settlement.
Reserve hold and later reserve release.
Cross-currency payout.
Bank amount differs by rounding tolerance.
One bank deposit covers multiple settlements.
Unknown fee produces low-confidence review.
User correction overrides future AI suggestions.
Journal debits do not equal credits.
OAuth token revoked.
Accounting API times out after accepting a request.

Copy-paste prompt — test suite

Create a comprehensive automated test plan and test fixtures for the reconciliation assistant.

Use synthetic data only.
Include unit, integration and end-to-end tests.
Focus on money precision, duplicate prevention, tenant isolation, reconciliation edge cases, low-confidence AI handling, journal balance, OAuth failures and external API uncertainty.
Do not use real seller or bank data.
Return a traceability table mapping each requirement to tests.

20. Deployment

Frontend — Vercel

Import the GitHub repository.
Select the frontend directory.
Add public frontend environment variables only.
Deploy and test login and API connectivity.

Backend — Render

Create a Python web service.
Set the backend root directory.
Add database, Redis, OAuth and AI secrets.
Run Alembic migrations as a controlled release step.
Create a separate worker service.

Database — Neon

Create a PostgreSQL project in the region closest to the backend.
Use the correct pooled/direct connection for the workload.
Enable backups appropriate to the plan.

Production checklist

HTTPS and secure cookies.
Database migrations complete.
Worker health visible.
OAuth callbacks use production URLs.
Sandbox flags disabled only after approval.
Error monitoring configured.
Backups and restore test complete.

21. Environment Variables

DATABASE_URL=
REDIS_URL=
APP_SECRET_KEY=
ENCRYPTION_KEY=
FRONTEND_URL=
BACKEND_URL=

AI_PROVIDER=
GEMINI_API_KEY=
OPENAI_API_KEY=
ANTHROPIC_API_KEY=

AMAZON_CLIENT_ID=
AMAZON_CLIENT_SECRET=
AMAZON_REDIRECT_URI=

QUICKBOOKS_CLIENT_ID=
QUICKBOOKS_CLIENT_SECRET=
QUICKBOOKS_REDIRECT_URI=

XERO_CLIENT_ID=
XERO_CLIENT_SECRET=
XERO_REDIRECT_URI=

EMAIL_API_KEY=
EMAIL_FROM=

Never commit real values. Commit only a .env.example file.

22. Cost Planning

Pricing changes frequently, so verify current prices before committing. A low-usage MVP can often begin on free or entry tiers, but production finance software should budget for reliable hosting, backups, monitoring, email, AI usage and developer-platform requirements.

| Stage | Typical approach |

| --- | --- |

| Prototype | CSV only, local development, AI Studio, test data. |

| Private MVP | Vercel, Render, Neon, Upstash, email, one AI provider. |

| Early SaaS | Paid backend/database tiers, worker, monitoring, backups, OAuth integrations. |

| Scale | Usage-based cost controls, queue scaling, regional requirements, support and compliance work. |

23. Common Mistakes

Using AI for arithmetic. Use Decimal-based code.
Calling AI for every row. Use approved mappings and cache.
Posting journals without approval. Separate proposed, approved and posted states.
Editing raw source data. Keep raw and normalized layers separate.
Ignoring duplicates. Add checksums, external IDs and idempotency keys.
Calling SKU P&L “net profit” without all costs. State data coverage clearly.
Building every API first. Validate the workflow using CSV.
Hard-coding account codes. Let each organization map its own Chart of Accounts.
Assuming an accounting API failure means nothing posted. Re-query before retrying.
No audit trail. Financial corrections must be traceable.

24. Recovery Prompts

Import failure

Inspect the CSV import failure without changing code first.
Identify the exact failing stage: upload, encoding, header detection, parsing, validation, database insert or normalization.
Show evidence from logs and provide the smallest safe fix.
Preserve raw data and idempotency.

OAuth failure

Diagnose this OAuth connection failure using the provider's current official documentation.
Check redirect URI, scopes, environment, state validation, token exchange, refresh-token storage and clock issues.
Do not expose secrets. Return a verification checklist before proposing code changes.

Duplicate journal risk

A journal-post request timed out and the system does not know whether the provider accepted it.
Do not retry immediately.
Design a safe recovery process using the stored request reference, provider query APIs, idempotency strategy and manual review.
Explain how to prevent a duplicate posting.

Wrong AI classification

Investigate why this fee classification is wrong.
Check approved mappings, normalization, cache key, prompt version, source context and confidence threshold.
Do not retrain or broadly rewrite the prompt first.
Propose the narrowest correction and tests to prevent recurrence.

25. Launch Checklist

CSV MVP reconciles synthetic settlements correctly.
Duplicate files and events are blocked.
Money calculations use Decimal.
Unknown classifications enter review.
Raw records cannot be edited.
All manual actions create audit logs.
Journal batches must balance.
External posting requires approval.
Amazon ingestion is idempotent and rate-limit aware.
QuickBooks/Xero tested in sandbox/demo.
Secrets are encrypted and absent from logs.
Backups and restoration have been tested.
Dashboard labels explain data limitations.
Terms, privacy and data-retention policies are prepared.

Official References

API versions, requirements, pricing and platform policies can change. Always verify the current official documentation before production implementation.

AI Builder Blueprint #2

Prepared by Imtiaz Ahmad · LinkedIn

AI Amazon Reconciliation Assistant — Beginner Build Guide

AI Amazon Reconciliation Assistant

Table of Contents

How to Use This Guide

1. What You Are Building

Import

Classify

Reconcile

Post

Explain

Alert

Final workflow

2. Accounts and Tools

3. Recommended Architecture

4. Build the MVP First

5. Create the Repository and Project Structure

6. Database Design

Non-negotiable database rules

7. CSV Import and Normalization

8. Fee Classification: Rules First, AI Second

Classification order

Example structured result

9. Build the Reconciliation Engine

Core calculation

Matching strategy

10. Bank Data: Start with CSV

11. Human Review Queue

12. Amazon SP-API Integration

Implementation flow

13. QuickBooks Online Integration

Safe flow

14. Xero Integration

15. Dashboard

Settlement status

Fee breakdown

SKU / ASIN P&L

Exceptions

16. Background Processing

Suggested jobs

Job safety

17. Alerts

18. Security and Compliance

19. Testing Plan

Minimum test cases

20. Deployment

Frontend — Vercel

Backend — Render

Database — Neon

Production checklist

21. Environment Variables

22. Cost Planning

23. Common Mistakes

24. Recovery Prompts

25. Launch Checklist

Official References