System Requirements Document for debet-kredit

1. Introduction

debet-kredit is a simple web application for a Shopee seller to record the finances of their online business using a plain debit/kredit (money-in / money-out) ledger. The product exists so that a solo seller can write down every rupiah that comes in and every rupiah that goes out, and then see where their business stands — without accounting jargon, without a complicated setup, and without a spreadsheet they have to maintain by hand.

The audience is the Pemilik Bisnis Shopee: an individual who runs a store on Shopee, handles marketplace payouts, shipping costs, ads and restock, and is not an accountant. They want a calm, honest, well-labelled tool where every number has a place. The product is deliberately narrow: it records debit and kredit entries for a Shopee business and shows the resulting position. It is not a general accounting suite, not an invoicing system, and not a tax tool.

2. System Overview

debet-kredit is delivered as a web application with a first-party custom interface and a backend that persists the seller's ledger. The seller reaches a public landing page, creates their own account, signs back in when they return, and then works inside three protected destinations: a dashboard that shows the financial position, a transaction list that shows what has been recorded, and a form that records a new debit or kredit entry.

The only active human actor is the Pemilik Bisnis Shopee. The application itself owns identity (self-service sign-up and returning login) and owns the ledger data. There is no marketplace integration, no bank feed, no multi-user collaboration, and no role hierarchy — the seller's own records are private to the seller.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is a browser-based web application. It is not a mobile app, not a desktop install, and not a headless API product. The interface is custom-built for this product rather than assembled from a third-party accounting platform.

Access ownership. The seller's ledger is durable, personal, and must be resumable across sessions, so the application owns identity. A first-time visitor can read the public landing page without any account. To record or review finances, the seller establishes their own identity through self-service sign-up, and on later visits verifies that identity through login. The three working destinations — Dashboard, Transactions, New Transaction — are reachable only after that verification. Sign-up and login are themselves reachable without being signed in, since a protected page cannot be the place where access to itself is created.

Current boundary. Everything described in this document is current: the landing page, self-service identity, the dashboard position summary, the transaction list, and the debit/kredit entry form, together with the backend storage that keeps them.

Explicit exclusions. The product is scoped to Shopee business finance recording only. It does not connect to Shopee, to banks, or to any external financial provider; it does not compute taxes, generate invoices, manage inventory, or produce formal accounting statements. Nothing in this document should be read as authorising those adjacent capabilities.

Future. No future-horizon requirements were accepted. Anything not stated here is out of scope for this generation.

2b. Source Content Inventory

No reference directive in this project declares a content_source, so no source content inventory is included.

2c. Page Content and Component Coverage

The page inventory below is the final, ordered page contract for this product.

Landing

• Purpose and information. The anonymous public entry. It explains, in plain Indonesian, that this is a simple web tool for recording the debit and kredit finances of a Shopee business, and it offers the two ways in: start recording (sign up) or return to existing records (login).
• Primary actions. Mulai catat — begin by creating an account, leading to Sign Up. Masuk — return to existing records, leading to Login.
• Supporting content. A short statement of what the tool does and does not do (records debit and kredit; does not do complicated accounting). A diagrammatic schematic of the Shopee money flow — order → payout → expense — drawn in thin transit-line strokes, red for money in and green for money out. A small ruled sample ledger strip showing the shape of a DEBET row and a KREDIT row so the visitor sees the product's core object before signing up.
• Domain entities. None persisted. The sample ledger strip is illustrative only and is not the seller's data.
• Component responsibilities. Hero headline block; ruled ledger strip; money-flow schematic; primary CTA; secondary login link; footer with product name.
• States. Loading: static content, no data fetch. Empty: not applicable. Success: the visitor reads the page and chooses an entry point. Error: not applicable. Recovery: if the visitor is already signed in, the entry points lead into the protected area instead of asking them to sign up again.

Sign Up

• Purpose and information. Lets a first-time seller create their own application identity so their ledger belongs to them and can be resumed later.
• Primary actions. Submit the sign-up form to create the account; then proceed into the protected area.
• Supporting content. A short statement of why an account is needed (so the records are kept and can be reopened). A link to Login for sellers who already have an account.
• Domain entities. Seller identity: the credentials and identifying details the seller supplies to own their ledger.
• Component responsibilities. Sign-up form (identity fields and credential fields); submit control; validation messaging; link to Login.
• States. Loading: submit control shows a pending state while the account is being created. Empty: the form starts blank. Success: the account is created and the seller is taken into the protected area, with the Dashboard as the natural first destination. Error: missing or invalid fields are reported next to the offending field; an identity that already exists is reported clearly with a route to Login. Recovery: the seller corrects the field and resubmits without losing what they already typed.

Login

• Purpose and information. Verifies a returning seller so they can reach the ledger they already recorded.
• Primary actions. Submit credentials to sign in; proceed to the protected area.
• Supporting content. A link to Sign Up for sellers who do not yet have an account.
• Domain entities. Seller identity (verification only; no new identity is created here).
• Component responsibilities. Login form; submit control; error messaging; link to Sign Up.
• States. Loading: submit control shows a pending state during verification. Empty: the form starts blank. Success: the seller is verified and lands in the protected area. Error: incorrect credentials are reported without revealing which part was wrong. Recovery: the seller retries; if they do not have an account, the Sign Up link is available.

Dashboard

• Purpose and information. Shows the seller's current financial position for the Shopee business, derived from the recorded debit and kredit entries. The balance figure is the masthead of the page: the largest element on screen, in tabular numerals, with a thin rule beneath it. Beside it, two colour-coded columns — DEBET in red and KREDIT in green — aligned to the same baseline.
• Primary actions. Read the position; go to New Transaction to record an entry; go to Transactions to review the full list.
• Supporting content. Totals for debit and kredit; the resulting balance; a short recent-activity strip of the latest recorded entries so the seller can confirm what they just wrote.
• Domain entities. Transaction (debit or kredit entries); the derived position (total debit, total kredit, balance).
• Component responsibilities. Balance masthead; DEBET and KREDIT total columns; recent-entries strip; navigation to the other working destinations.
• States. Loading: the position and recent entries are being fetched; the masthead area holds its space so the layout does not jump. Empty: no entries recorded yet — the balance reads zero and the page states plainly that no transactions have been recorded, with a direct route to New Transaction. Success: totals and balance reflect every recorded entry. Error: if the position cannot be loaded, the page says so and offers a retry rather than showing a misleading zero. Recovery: retry reloads the position; the seller can still navigate to Transactions or New Transaction.

Transactions

• Purpose and information. Shows the list of financial entries the seller has recorded for the business, so they can review and confirm their records.
• Primary actions. Read the list; open New Transaction to add another entry.
• Supporting content. Per row: date, description, a type chip (red DEBET / green KREDIT), and the amount right-aligned in tabular numerals. Rows are dense and ruled, like timetable lines.
• Domain entities. Transaction records with their date, description, type (debit or kredit), and amount.
• Component responsibilities. Ruled transaction list; type chips; right-aligned tabular amounts; empty-state block; route to New Transaction.
• States. Loading: rows are being fetched; a ruled placeholder holds the list's shape. Empty: no entries yet — a plain statement that nothing has been recorded, with a direct route to New Transaction. Success: every recorded entry appears as a ruled row with its type and amount. Error: if the list cannot be loaded, the page says so and offers a retry. Recovery: retry reloads the list; the seller can still record a new entry.

New Transaction

• Purpose and information. Records one financial entry for the Shopee business: its type (debit or kredit), its amount, and enough description to recognise it later.
• Primary actions. Choose the type — DEBET (money in) or KREDIT (money out); enter the amount; enter a description and date; save the entry.
• Supporting content. Clear labelling of which type means money in and which means money out, so the seller cannot confuse them. A visible indication of what will be saved before committing.
• Domain entities. Transaction: type (debit or kredit), amount, description, date.
• Component responsibilities. Type selector with the two colour-coded options; amount input in tabular numerals; description input; date input; save control; validation messaging; route back to Transactions or Dashboard.
• States. Loading: the save control shows a pending state while the entry is being written. Empty: the form starts blank with no type preselected, so the seller makes a deliberate choice. Success: the entry is saved, the seller is returned to the ledger view where the new row is visible, and the balance figure counts up to its new value. Error: a missing type, a missing or non-numeric amount, or a missing description is reported next to the offending field and nothing is saved. Recovery: the seller corrects the field and saves again; the entered values are preserved.

3. Functional Requirements

Each requirement below is a distinct story point. Provenance is marked as explicit (stated by the user), basic_default (an accepted default), or required_inference (an indispensable mechanic needed to make an accepted journey usable).

FR-1 — Record Shopee business finances in a web app (explicit) As a Pemilik Bisnis Shopee, I should be able to record the finances of my Shopee business in a web application, so that my money-in and money-out are written down in one place instead of scattered.

• Trigger/input: the seller opens the web application in a browser.
• Observable result: the seller has a working web tool in which their business finances can be recorded and reviewed.
• Access state: the landing page is reachable without an account; the recording area requires the seller to be signed in.
• Failure/recovery: if the app cannot be reached, the seller retries in the browser.
• Continuation: the seller proceeds to record an entry or review existing records.

FR-2 — Record both debit and kredit entries (explicit) As a Pemilik Bisnis Shopee, I should be able to record each entry as either a debit or a kredit, so that money coming in and money going out are distinguished in my records.

• Trigger/input: the seller chooses DEBET or KREDIT and supplies the entry's amount and description.
• Observable result: the saved entry carries its type, and appears in the ledger with the matching colour-coded chip (red DEBET, green KREDIT).
• Access state: signed in.
• Failure/recovery: if no type is chosen, the entry is not saved and the seller is told to choose one.
• Continuation: the seller records another entry or reviews the list.

FR-3 — Keep the tool simple to use (explicit) As a Pemilik Bisnis Shopee, I should be able to use the tool without accounting knowledge or a complicated setup, so that recording my finances takes as little effort as writing a line in a notebook.

• Trigger/input: the seller uses the app for the first time and on repeat visits.
• Observable result: recording an entry requires only choosing a type, entering an amount, and describing it; the interface uses plain labels rather than accounting terminology.
• Access state: applies throughout the signed-in area.
• Failure/recovery: if the seller is unsure what a field means, the labelling states plainly which type is money in and which is money out.
• Continuation: the seller completes the entry without leaving the flow.

FR-4 — Establish a first-use identity (required_inference) As a Pemilik Bisnis Shopee, I should be able to create my own account on first use, so that my ledger belongs to me and can be reopened later.

• Trigger/input: the seller chooses to start recording from the landing page and submits the sign-up form.
• Observable result: an account exists for the seller and they enter the protected area.
• Access state: Sign Up is reachable without being signed in; the protected destinations are not.
• Failure/recovery: invalid or incomplete fields are reported next to the field; an already-existing identity is reported with a route to Login.
• Continuation: the seller lands in the protected area and can record their first entry.

FR-5 — Verify identity on return (required_inference) As a Pemilik Bisnis Shopee, I should be able to sign back in, so that I can reach the records I saved earlier.

• Trigger/input: the returning seller submits their credentials on Login.
• Observable result: the seller is verified and their previously recorded ledger is available again.
• Access state: Login is reachable without being signed in; the protected destinations require the verification to have succeeded.
• Failure/recovery: incorrect credentials are reported without disclosing which part was wrong; the seller retries or follows the link to Sign Up.
• Continuation: the seller lands in the protected area with their records intact.

FR-6 — Persist debit, kredit and the resulting position (required_inference) As a Pemilik Bisnis Shopee, I should have my entries and the resulting financial position stored, so that what I recorded is still there when I come back.

• Trigger/input: the seller saves an entry.
• Observable result: the entry is written to backend storage and is included in the totals and balance shown on the Dashboard and in the list on Transactions.
• Access state: signed in; the stored records are the seller's own.
• Failure/recovery: if the entry cannot be written, the seller is told the save failed and the entry is not silently lost; the seller can retry the save.
• Continuation: the seller sees the saved entry in the ledger and the updated balance.

FR-7 — See the current financial position (required_inference) As a Pemilik Bisnis Shopee, I should be able to see my current position — total debit, total kredit, and the resulting balance — so that I know where my business stands.

• Trigger/input: the seller opens the Dashboard.
• Observable result: the balance is shown at display scale in tabular numerals, with DEBET and KREDIT totals beside it, all derived from the recorded entries.
• Access state: signed in.
• Failure/recovery: if the position cannot be loaded, the page says so and offers a retry instead of showing a misleading zero.
• Continuation: the seller records a new entry or reviews the transaction list.

FR-8 — Review recorded transactions (required_inference) As a Pemilik Bisnis Shopee, I should be able to review the list of entries I have recorded, so that I can confirm what has been written down.

• Trigger/input: the seller opens Transactions.
• Observable result: each recorded entry appears as a ruled row with its date, description, type chip, and right-aligned tabular amount.
• Access state: signed in.
• Failure/recovery: if the list cannot be loaded, the page says so and offers a retry.
• Continuation: the seller records another entry or returns to the Dashboard.

FR-9 — Record a new entry from the ledger (required_inference) As a Pemilik Bisnis Shopee, I should be able to record a new entry from the working area, so that adding a transaction is one short step from where I am looking.

• Trigger/input: the seller opens New Transaction, chooses the type, enters the amount and description, and saves.
• Observable result: the entry is saved, the seller returns to the ledger view where the new row is visible, and the balance figure counts up to its new value.
• Access state: signed in.
• Failure/recovery: a missing type, a missing or non-numeric amount, or a missing description is reported next to the field and nothing is saved; the seller's entered values are preserved for correction.
• Continuation: the seller records another entry or reviews the updated list.

4. User Personas

Pemilik Bisnis Shopee

Product context. This person runs a small online store on Shopee in Indonesia. Money arrives as marketplace payouts and leaves again as shipping costs, ads, restock and day-to-day operating expenses. They are not an accountant and do not want accounting software; they want a plain, honest record of what came in and what went out, and a clear answer to "where do I stand right now?" Their working context is a browser, often in short bursts between other tasks, and their records are personal to their own business.

Primary goal. To keep a simple, trustworthy debit/kredit record of the Shopee business and to be able to see the resulting financial position at a glance.

Distinct accepted responsibilities.

• Creating their own account on first use so the ledger belongs to them and can be reopened.
• Signing back in on return visits to reach the records they already saved.
• Recording each financial entry as either a debit (money in) or a kredit (money out), with an amount and a description.
• Reviewing the list of recorded entries to confirm what has been written down.
• Reading the current position — total debit, total kredit, and the resulting balance — to know where the business stands.

Relevant inputs and decisions. For each entry: which type it is (money in or money out), how much, what it was for, and when it happened. The recurring decision is the type choice, which is why the interface labels it plainly and colour-codes it rather than relying on accounting vocabulary.

Interactions with other accepted participants. There are none. This is a single-owner tool: the seller is the only human actor, and no other person, counterparty or collaborator participates in the recorded lifecycles. The application itself owns identity and storage on the seller's behalf.

Observable success. The seller can open the app, write down an entry in a few seconds, see it appear as a ruled row in the ledger, and see the balance figure update to reflect it — with the whole record still there on the next visit.

Constraints carried from the source. The tool is a web application; it is specifically for Shopee business finances; and it must stay simple.

5. Core User Flows

Flow A — First use: from landing page to first recorded entry

1. The seller opens the debet-kredit web application in a browser and lands on Landing without any account. The page states plainly that this is a simple tool for recording the debit and kredit finances of a Shopee business, and shows the ruled sample ledger strip and the Shopee money-flow schematic so the seller can see what the product does.
2. The seller reads the page and chooses Mulai catat, which takes them to Sign Up.
3. On Sign Up, the seller supplies their identity and credential details and submits the form. The submit control shows a pending state while the account is created.
4. Failure branch: if a field is missing or invalid, the error is reported next to that field and nothing is created; the seller corrects it and resubmits with their other values preserved. If the identity already exists, the page says so and offers the route to Login.
5. On success, the seller's account exists and they enter the protected area, arriving at Dashboard.
6. Dashboard shows the position for a business with no entries yet: the balance reads zero and the page states plainly that no transactions have been recorded, with a direct route to New Transaction.
7. The seller follows that route to New Transaction. The form is blank with no type preselected, so the choice is deliberate.
8. The seller chooses DEBET (money in) — or KREDIT (money out) — enters the amount, enters a description, and confirms the date. The form shows what will be saved before they commit.
9. The seller saves. The save control shows a pending state while the entry is written.
10. Failure branch: if the type, amount or description is missing or the amount is not a number, the error is reported next to the offending field and nothing is saved; the seller's entered values are preserved and they correct and save again.
11. On success, the entry is written to backend storage and the seller is returned to the ledger view, where the new entry appears as a ruled row with its colour-coded type chip and right-aligned tabular amount. The balance figure counts up to its new value.
12. Next step: the seller records another entry, or opens Transactions to review the full list, or returns to Dashboard to read the updated position.

Flow B — Returning visit: signing back in and reviewing the position

1. The seller returns to the application and lands on Landing. Because they already have an account, the entry points lead into the protected area rather than asking them to sign up again.
2. The seller chooses Masuk and arrives at Login.
3. The seller submits their credentials. The submit control shows a pending state during verification.
4. Failure branch: if the credentials are incorrect, the error is reported without disclosing which part was wrong; the seller retries, or follows the link to Sign Up if they do not have an account.
5. On success, the seller is verified and lands in the protected area with their previously recorded ledger intact.
6. The seller opens Dashboard and reads the position: the balance at display scale in tabular numerals, with the DEBET total in red and the KREDIT total in green aligned to the same baseline, plus the recent-activity strip of the latest entries.
7. Failure branch: if the position cannot be loaded, the page says so and offers a retry rather than showing a misleading zero; the seller can still navigate to Transactions or New Transaction.
8. Next step: the seller opens Transactions to review the full list, or goes to New Transaction to add an entry.

Flow C — Reviewing the recorded transactions

1. From the signed-in area, the seller opens Transactions.
2. The list loads; while it is loading, a ruled placeholder holds the list's shape so the layout does not jump.
3. Each recorded entry appears as a dense, ruled row: date, description, a solid type chip (red DEBET / green KREDIT), and the amount right-aligned in tabular numerals — read like timetable lines.
4. Empty branch: if nothing has been recorded yet, the page states plainly that there are no entries and offers a direct route to New Transaction.
5. Failure branch: if the list cannot be loaded, the page says so and offers a retry; the seller can still record a new entry.
6. Next step: the seller opens New Transaction to add another entry, or returns to Dashboard to read the position.

Flow D — Recording an additional entry

1. From Dashboard or Transactions, the seller opens New Transaction.
2. The seller chooses the type — DEBET for money in or KREDIT for money out — using the plainly labelled, colour-coded selector.
3. The seller enters the amount in tabular numerals, a description, and the date.
4. The seller saves. The save control shows a pending state while the entry is written.
5. Failure branch: a missing type, a missing or non-numeric amount, or a missing description is reported next to the offending field and nothing is saved; the seller's values are preserved for correction.
6. On success, the entry is stored and the seller returns to the ledger view where the new row is visible; the balance figure counts up over 400ms to its new value.
7. Next step: the seller records another entry or reviews the updated list.

6. Visuals, Colors and Theme

The visual language is typographic infrastructure for a Shopee seller's ledger, after the muse Erik Spiekermann: typography as infrastructure, warm neutrals with signal colours used like transit lines, and zero decorative noise. The headline idea is that the product is the interface itself — a printed timetable, not a SaaS dashboard.

Colour tokens (light mode).

Proportion: 70% paper ground, 20% white surfaces, 6% red, 4% green. Colour is wayfinding, never decoration. No blue or indigo anywhere — no #0057FF, #2563EB, #4F46E5 or neighbours.

Typography. Headings and body both use Fira Sans — no Inter, Roboto, Poppins, system-ui or any neutral default sans. Three weights only: 700 for page titles and the balance figure, 600 for section labels set in small caps with 0.08em tracking, 400 for body. Headlines are flush-left, ragged-right, tight leading (1.05) and large. Labels are uppercase small caps, never title case. Numerals are always tabular.

Type scale: 1.25 modular, 16px base — 48 / 38 / 30 / 24 / 19 / 16 / 13. Display balance figure clamps 40px mobile → 84px desktop. Page titles clamp 28px → 44px. Body 16px with 1.55 line-height.

Shape language. Rectilinear and honest: 4px radius on inputs and buttons, 0px on cards and table rows, 2px solid rules as dividers, 1px warm-grey borders. No pills, no blobs, no soft shadows. Buttons are solid rectangles with a 2px bottom rule in a darker shade of their own colour — a physical, pressable feel like a Braun control or a station sign.

Layout. A strict 12-column grid with a persistent left rail on desktop — numbered nav items 01 Dashboard, 02 Transaksi, 03 Catat Baru — collapsing to a bottom tab bar on mobile. The dashboard opens with a full-width ledger strip: a huge tabular balance figure on the left, and two colour-coded columns — DEBET in red, KREDIT in green — aligned to the same baseline on the right. Transaction rows are dense, ruled, aligned label/value pairs like a timetable: date | description | type chip | amount, with amounts right-aligned in tabular numerals. Every section header carries a thin horizontal rule spanning the full content width.

Imagery. No photography and no illustration for its own sake. The visual language is diagrammatic: thin-line pictograms for debit (arrow into a box) and credit (arrow out), a small schematic of the Shopee order → payout → expense flow on the landing page drawn in 2px transit-line strokes in red and green, and ruled data blocks.

Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, card text and controls remain entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Decoration and motion may be cropped, bled, rotated or overlapped as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The landing page is a printed timetable, not a SaaS hero.

The public entry is a full-bleed warm-paper field (#F2EDE3) split by a single 2px horizontal rule running edge to edge.

Above the rule: an oversized flush-left headline in Fira Sans 700 at clamp(40px, 8vw, 96px) reading "Catat debit. Catat kredit. Tahu posisi bisnismu." stacked in three lines, each line starting at a different column of the 12-column grid so it steps down and to the right. Ragged-right, tight leading, no centring.

Below the rule: a live-looking ledger strip — three ruled rows with DEBET in red and KREDIT in green, tabular amounts right-aligned at the far edge — so the product's core object is the first thing the visitor sees. A single solid red rectangular CTA, "Mulai catat", is pinned to the left under the last row, carrying a 2px darker bottom rule instead of a shadow. A secondary "Masuk" link sits beside it for returning sellers.

Beside the ledger strip: the small diagrammatic Shopee money-flow schematic — order → payout → expense — drawn in 2px transit-line strokes, red for money in and green for money out, with thin-line pictograms for debit (arrow into a box) and credit (arrow out).

No gradient, no blob, no centred stack, no blue CTA. The composition is a station sign: every number has a place, nothing hides. The concept recomposes only accepted content and controls — the headline, the two entry points, the sample ledger rows, and the money-flow schematic — and introduces no new behaviour or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The ruled ledger strip below the 2px horizontal rule: three timetable rows with red DEBET and green KREDIT columns, tabular amounts right-aligned to the grid edge, and the solid red "Mulai catat" control pinned beneath the last row.
• Input → transformation → outcome thesis. On first paint, the ledger rows enter as a single staggered fade-up — 60ms apart, 200ms each — so the visitor's eye is walked down the strip in reading order and arrives at the CTA already understanding the product's core object. Nothing else moves; the headline and the rule are present from the first frame.
• Motion vocabulary. Functional and short: 140ms ease-out on hover and focus, instant state changes, no bounce, no parallax, no decorative loops. The only entrance motion is the staggered fade-up of the ledger rows.
• Composed first frame. Warm paper field, the 2px rule edge to edge, the three-line headline stepped down and right across the grid, and the ledger strip fully composed below the rule with the red CTA in place — a printed timetable at rest.
• Reduced-motion state. With prefers-reduced-motion, the staggered fade-up is removed entirely: the ledger rows are simply present in their final positions from the first frame, fully readable, with the CTA in place. No content is hidden behind motion.

In-app motion. Number changes in the balance figure count up over 400ms when a transaction is saved — a needle sweep, precise, never playful. Under reduced motion this becomes an instant value change. Hover and focus transitions are 140ms ease-out; state changes are otherwise instant.

9. Non-Functional Requirements

• NFR-1 — Web delivery (explicit). The product is delivered as a web application used in a browser. Rationale: the user explicitly asked for a web tool.
• NFR-2 — Simplicity (explicit). The interface must stay simple: plain labels, no accounting terminology, and no step in the recording flow beyond choosing a type, entering an amount, and describing the entry. Rationale: the user explicitly required the tool to be simple.
• NFR-3 — Shopee business scope (explicit). The product is scoped to recording the finances of a Shopee business. Rationale: the user explicitly scoped the tool to Shopee business finance.
• NFR-4 — Durable, private records (required_inference). Recorded entries and the derived position must be persisted in backend storage and bound to the seller who created them, so that records survive across sessions and are visible only to their owner. Rationale: the accepted journey requires the seller to return and find their records intact.
• NFR-5 — Readable numerals (basic_default). Amounts and the balance figure are set in tabular numerals so columns align and figures can be compared at a glance. Rationale: the creative direction specifies tabular numerals throughout.
• NFR-6 — Responsive integrity (basic_default). Headlines, labels, numbers, card text and controls remain entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, with no other element covering them. Rationale: the creative direction's readable-text rule.
• NFR-7 — Reduced motion (basic_default). When the user prefers reduced motion, the staggered ledger-row entrance and the balance count-up are replaced by instant, fully readable static states. Rationale: the creative direction's motion brief.
• NFR-8 — Accessible contrast (basic_default). Text and controls meet accessible contrast against the warm paper ground and white surfaces, including the red DEBET and green KREDIT signal colours. Rationale: the palette must remain legible for the numbers the seller reads.

10. Tech Stack

• Frontend: React — a single-page web application with the custom interface described in section 2c.
• Backend: Python with FastAPI — serves the application's data and owns identity verification and ledger persistence.
• Storage: a relational database appropriate to the ledger records (transactions with type, amount, description, date, and owning seller) and to seller identity.
• Containerisation: Docker with docker-compose for local and single-host deployment.
• Kubernetes: not required for this product's deployment; omitted.

No marketplace integration, bank integration, or third-party accounting platform is part of the stack.

11. Assumptions and Constraints

Constraints (from the user).

• The product is a web application.
• The product is specifically for recording the finances of a Shopee business.
• The product must be simple to use.

Assumptions (narrow and labelled).

• Assumption — single owner per account. Each account belongs to one seller and holds that seller's own ledger; no sharing, collaboration, or role hierarchy is assumed, because no such requirement was accepted.
• Assumption — manual entry. Entries are written by the seller by hand; no automatic import from Shopee, banks, or any other source is assumed, because none was requested.
• Assumption — currency. Amounts are recorded in Indonesian rupiah, consistent with the seller's context; no multi-currency handling is assumed.
• Assumption — identity is application-owned. Because the seller's ledger is durable and personal and must be resumed across sessions, the application owns identity through self-service sign-up and returning login. This is a required_inference, not a source-stated feature.
• Assumption — no differentiated permissions. Application identity establishes ownership of one's own records only; it does not establish roles, tiers, or differentiated visibility over shared state, because no such requirement was accepted.

Explicit exclusions.

• No connection to Shopee, banks, or any external financial provider.
• No tax computation, invoicing, inventory management, or formal accounting statements.
• No multi-user collaboration or role-based access control.

Future. No future-horizon requirements were accepted for this generation.

12. Glossary

• Debet (DEBET) — money coming in to the Shopee business; shown in transit-signal red (#C8341F).
• Kredit (KREDIT) — money going out of the Shopee business; shown in deep transit green (#1F6B4A).
• Pemilik Bisnis Shopee — the sole active human actor: the owner of a Shopee store who records and reviews the business's finances.
• Transaksi (Transaction) — one recorded financial entry, carrying a type (debit or kredit), an amount, a description, and a date.
• Posisi keuangan (Financial position) — the derived state of the business: total debit, total kredit, and the resulting balance.
• Ledger strip — the full-width ruled band showing the balance figure alongside the DEBET and KREDIT columns, aligned to the same baseline.
• Type chip — the solid colour-coded marker on a transaction row identifying it as DEBET (red) or KREDIT (green); the only rounded element in the row.
• Tabular numerals — figures set at a fixed width so amounts align vertically and can be compared at a glance.