System Requirements Document for mammoth-akuntansi

1. Introduction

mammoth-akuntansi is a mobile-first accounting application for Indonesian small businesses. It exists so that a small-business owner — a warung, a workshop, a one-person trading operation — can record daily income and expense transactions on a phone, between jobs and away from a desk, and then read a profit-and-loss statement and a cash-flow statement they can trust without hiring a dedicated accountant. It equally serves accounting staff who keep books for more than one client and must produce those same reports on demand.

The product intent is deliberately narrow and complete: daily transaction recording (income and expenses) and financial reports (profit-and-loss and cash flow), delivered as a mobile application with a full first-version feature set. The application is not a general ledger suite, not an invoicing system, and not a payroll tool. It is a bookkeeping instrument: a small number of honest controls, one alignment the user learns once, and numbers that behave predictably.

The audience is two accepted human roles — the Small Business Owner and the Accounting Staff member — both of whom record transactions and both of whom read reports, but whose working contexts differ in who owns the books and why the report is needed.

2. System Overview

mammoth-akuntansi is delivered as a mobile application with an application-owned identity boundary and custom first-party UI. A user arrives anonymously at a public entry surface, establishes their own account through self-service enrollment, and thereafter verifies themselves through login before reaching protected accounting records and reports. All accounting data — transactions, their amounts, dates, categories, and the derived reports — is durable, application-owned state bound to the correct participant.

The current delivery covers:

• Daily transaction recording — creating, editing, and browsing income and expense transactions, each carrying an amount, a date, a direction (income or expense), and a description.
• Financial reporting — a profit-and-loss statement and a cash-flow statement, both derived from the recorded transactions.
• A protected accounting hub — a dashboard that summarizes the current period's position and routes the user to recording and reporting.
• Role-aware access — the Small Business Owner and the Accounting Staff member are distinguished in their access to shared bookkeeping data.

Actors in the current system:

Narrow exclusions for the current version: no invoicing, no accounts-receivable/payable aging, no inventory, no payroll, no tax filing, no bank-feed integration, no multi-currency, and no third-party accounting-provider surface. These are not accepted current capabilities and are not built.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. mammoth-akuntansi is a first-party mobile application. Its screens are custom-built, not embedded from a provider, and its accounting records live in application-owned storage. There is no external accounting provider, no headless delivery channel, and no provider-owned surface in the current version. The mobile application is the whole product.

Access ownership. Because a user must privately own and resume durable, actor-specific accounting state — their transactions and their reports — and because recorded transactions constitute a commitment of value that must remain bound to the correct participant, the application owns identity. A first-time user establishes their own account through self-service enrollment; a returning user verifies themselves through login. The public entry surface and the two identity surfaces are reachable anonymously; the accounting hub, the transaction browse surface, the transaction recording workspace, and the reports surface are protected and require an established identity. Access to shared bookkeeping data is role-aware: the Small Business Owner and the Accounting Staff member are distinguished in what they may reach and act upon.

Current versus future. Everything described in this document is current. No future-horizon capability has been accepted; the "complete feature set" requested is the transaction-recording and reporting set defined here, not an open-ended roadmap. Any capability not listed in Section 3 is out of scope for this version.

2c. Page Content and Component Coverage

The application comprises seven pages. Each is described once below with its information and state, its primary and supporting actions, the domain entities it touches, its component responsibilities, and its applicable loading, empty, success, error, and recovery states.

Landing

• Information and state. Anonymous public entry. Presents the product's purpose and its two core functions — daily transaction recording and financial reporting — and names who it is for (small-business owners and accounting staff). No accounting data is shown; the ledger object displayed is illustrative of the product's output, not a user's real figures.
• Primary action. Begin recording — routes an unauthenticated visitor to Sign Up.
• Supporting actions. Navigate to Login for a returning user; read the product explanation and the instrument facts pinned along the bottom rule.
• Domain entities. None persisted. Displays the shape of a transaction ledger (income, expense, net, cash) as a static instrument object.
• Component responsibilities. Hero panel with kicker, headline, and a single accent rule; a flat ledger object with four label/value rows; a solid ink call-to-action bar with the accent arrow glyph; a plain text link to Login; a full-bleed bottom rule carrying three small-caps instrument facts.
• States. Loading: none required — the page is static. Empty: not applicable. Success: the visitor understands the product and chooses Sign Up or Login. Error: not applicable. Recovery: not applicable.

Login

• Information and state. Anonymous identity-access surface for a returning user. Collects the credentials that identify an existing account.
• Primary action. Verify identity and continue into the protected accounting hub.
• Supporting actions. Navigate to Sign Up if the visitor has no account; correct a mistyped credential.
• Domain entities. User identity (email/identifier and secret).
• Component responsibilities. Credential fields with small-caps labels; a solid ink submit bar; an inline error region; a link to Sign Up.
• States. Loading: submit bar shows an in-progress state while verification runs. Empty: fields start blank with labels visible. Success: the user is admitted to the Dashboard. Error: invalid credentials produce an inline, non-destructive message and the fields remain editable. Recovery: the user retries, or leaves for Sign Up.

Sign Up

• Information and state. Anonymous identity-access surface for a first-time user. Collects the minimum information needed to establish an account and the role the user will hold.
• Primary action. Create the account and enter the protected accounting hub.
• Supporting actions. Navigate to Login if an account already exists; correct a rejected field.
• Domain entities. User identity (identifier, secret, role selection).
• Component responsibilities. Enrollment fields with small-caps labels; role selection control; a solid ink submit bar; an inline error region; a link to Login.
• States. Loading: submit bar shows an in-progress state while the account is created. Empty: fields start blank with labels visible. Success: the account is created and the user lands in the Dashboard. Error: a rejected identifier or an unmet field requirement produces an inline message with the offending field marked. Recovery: the user corrects the field and resubmits, or leaves for Login.

Dashboard

• Information and state. Protected accounting hub. Shows the selected period, one large net-position readout, a two-column income/expense pair, a compact cash-flow bar diagram, and the five most recent ledger rows. All figures derive from the user's recorded transactions.
• Primary action. Record a new transaction — routes to New Transaction.
• Supporting actions. Change the reporting period; open the full transaction list; open Reports; open a recent ledger row.
• Domain entities. Transaction (aggregated), period, net position, income total, expense total, cash-flow bands.
• Component responsibilities. Period selector; net-position readout as the largest element on the screen; income/expense label-value pair; cash-flow bar diagram; recent-rows list using the shared ledger-row alignment; section labels in small caps over full-width hairlines.
• States. Loading: the net-position figure and the cash-flow bars resolve on first load; the readout counts up once and the bars grow once from the baseline. Empty: with no transactions in the period, the readout shows a zero position and the recent-rows region shows a single geometric line diagram of a ruled ledger with one accent tick, plus a prompt to record the first transaction. Success: the period's position is legible at a glance. Error: if figures cannot be retrieved, the affected region shows an inline message and a retry control rather than a stale or fabricated number. Recovery: retry reloads the period; the user can still navigate to New Transaction.

Transactions

• Information and state. Protected, revisitable browse and overview destination for recorded daily income and expense transactions. Lists transactions with date, description, direction, and amount, using the shared ledger-row alignment.
• Primary action. Open a transaction to view or edit it.
• Supporting actions. Filter or narrow the list by period or direction; start a new transaction; return to the Dashboard.
• Domain entities. Transaction (amount, date, direction, description, category).
• Component responsibilities. Filter/period control; transaction list of ledger rows with a leading icon tile distinguishing income (arrow-down-left) from expense (arrow-up-right); empty-state diagram; per-row navigation.
• States. Loading: the list shows a loading state while records are fetched. Empty: no recorded transactions shows the ruled-ledger line diagram and a prompt to record the first one. Success: the user locates and opens the intended transaction. Error: a failed fetch shows an inline message with retry; the list is not silently shown as empty. Recovery: retry refetches; the user may still start a new transaction.

New Transaction

• Information and state. Protected, focused mobile workspace for creating and editing a single daily income or expense record. Shows the direction being recorded, the amount, the date, and the description.
• Primary action. Save the transaction.
• Supporting actions. Switch direction between income and expense; set or change the date; enter or edit the description; cancel and return without saving; when editing an existing record, modify its fields.
• Domain entities. Transaction (amount, date, direction, description, category).
• Component responsibilities. Direction segmented control with a sliding indicator; amount field set as display type with a muted currency symbol; date field; description field; solid ink save bar; inline validation region.
• States. Loading: when editing, the existing record is fetched before the fields populate. Empty: a new record starts with the direction defaulted, the date defaulted to today, and amount and description blank. Success: the record is saved and the user returns to the transaction list or the Dashboard with the new row visible. Error: a missing or invalid amount, or a save failure, produces an inline message and preserves the entered values. Recovery: the user corrects the field and resaves, or cancels without losing the rest of the form.

Reports

• Information and state. Protected financial reporting destination. Presents a profit-and-loss statement as a stepped statement with indented subtotals and a double hairline above net profit, and a cash-flow statement as a three-band operations/investing/financing diagram with aligned figures beneath. Both are derived from recorded transactions for the selected period.
• Primary action. Read the selected report for the selected period.
• Supporting actions. Switch between profit-and-loss and cash flow; change the reporting period; return to the Dashboard.
• Domain entities. Transaction (aggregated), period, revenue, expense, net profit, cash-flow bands (operations, investing, financing).
• Component responsibilities. Report-type segmented control; period selector; stepped statement layout with indented subtotals; three-band cash-flow diagram; aligned label/value figures; section labels in small caps over hairlines.
• States. Loading: the report resolves while figures are computed. Empty: a period with no transactions shows the statement structure with zero figures and a note that no transactions were recorded in the period. Success: the user reads a trustworthy statement for the period. Error: a failed computation shows an inline message with retry rather than partial or invented figures. Recovery: retry recomputes; the user may change the period.

3. Functional Requirements

Each requirement below is a distinct story point with its provenance, lifecycle facts, and observable acceptance.

FR-1 — Mobile accounting application (explicit) As a Small Business Owner or Accounting Staff member, I should use mammoth-akuntansi as a mobile application so that I can keep books from a phone wherever I am.

• Trigger/input: the user opens the application on a mobile device.
• Observable result: the application renders and is fully usable at mobile viewport widths.
• Access state: the public entry surface is reachable anonymously; protected surfaces require an established identity.
• Failure/recovery: not applicable at this level.
• Continuation: the user proceeds to the entry surface or, if already verified, to the accounting hub.

FR-2 — Daily income and expense recording (explicit) As a Small Business Owner or Accounting Staff member, I should record daily income and expense transactions so that the books stay current.

• Trigger/input: the user opens New Transaction and enters a direction (income or expense), an amount, a date, and a description.
• Observable result: the transaction is saved and appears in the transaction list and in the dashboard's recent rows.
• Access state: protected; requires an established identity.
• Failure/recovery: an invalid or missing amount, or a save failure, shows an inline message and preserves the entered values so the user can correct and resave.
• Continuation: the user returns to the transaction list or the dashboard and sees the new row.

FR-3 — Editing a recorded transaction (explicit) As a Small Business Owner or Accounting Staff member, I should edit a recorded transaction so that a mistake in the books can be corrected.

• Trigger/input: the user opens an existing transaction from the transaction list.
• Observable result: the changed amount, date, direction, or description is saved and reflected in the list and in the derived reports.
• Access state: protected; requires an established identity.
• Failure/recovery: a save failure shows an inline message and preserves the edited values.
• Continuation: the user returns to the transaction list with the corrected row visible.

FR-4 — Browsing recorded transactions (explicit) As a Small Business Owner or Accounting Staff member, I should browse my recorded transactions so that I can review and find what has been entered.

• Trigger/input: the user opens the transaction list and optionally narrows it by period or direction.
• Observable result: the matching transactions are listed with date, description, direction, and amount.
• Access state: protected; requires an established identity.
• Failure/recovery: a failed fetch shows an inline message with retry rather than an empty list.
• Continuation: the user opens a transaction to view or edit it, or starts a new one.

FR-5 — Profit-and-loss report (explicit) As a Small Business Owner or Accounting Staff member, I should read a profit-and-loss report so that I understand whether the business made or lost money in a period.

• Trigger/input: the user opens Reports, selects profit-and-loss, and selects a period.
• Observable result: a stepped statement shows revenue, expense, indented subtotals, and net profit for the period, with a double hairline above net profit.
• Access state: protected; requires an established identity.
• Failure/recovery: a failed computation shows an inline message with retry rather than partial figures.
• Continuation: the user changes the period or switches to the cash-flow report.

FR-6 — Cash-flow report (explicit) As a Small Business Owner or Accounting Staff member, I should read a cash-flow report so that I understand how cash moved through the business in a period.

• Trigger/input: the user opens Reports, selects cash flow, and selects a period.
• Observable result: a three-band operations/investing/financing diagram is shown with aligned figures beneath each band.
• Access state: protected; requires an established identity.
• Failure/recovery: a failed computation shows an inline message with retry rather than partial figures.
• Continuation: the user changes the period or switches to the profit-and-loss report.

FR-7 — Protected accounting hub (required_inference) As a Small Business Owner or Accounting Staff member, I should land on a protected hub after verifying myself so that I can see the current position and reach recording and reporting.

• Trigger/input: the user completes login or sign-up.
• Observable result: the dashboard shows the selected period, the net-position readout, the income/expense pair, the cash-flow bar diagram, and the five most recent ledger rows.
• Access state: protected; requires an established identity.
• Failure/recovery: if figures cannot be retrieved, the affected region shows an inline message and a retry control.
• Continuation: the user records a new transaction, opens the transaction list, or opens Reports.

FR-8 — Self-service enrollment (required_inference) As a first-time Small Business Owner or Accounting Staff member, I should create my own account so that I can begin keeping books without waiting for an invitation or provisioning.

• Trigger/input: the user chooses to begin from the public entry surface and submits the enrollment fields, including their role.
• Observable result: an account is created and the user enters the protected accounting hub.
• Access state: anonymous entry; the account becomes the identity for all protected surfaces.
• Failure/recovery: a rejected identifier or unmet field requirement produces an inline message with the offending field marked, and the user corrects and resubmits.
• Continuation: the user lands on the Dashboard and can record a first transaction.

FR-9 — Returning verification (required_inference) As a returning Small Business Owner or Accounting Staff member, I should verify myself through login so that I can resume access to my durable accounting records and reports.

• Trigger/input: the user submits their credentials on the login surface.
• Observable result: the user is admitted to the protected accounting hub with their own records.
• Access state: anonymous entry; success establishes the protected session.
• Failure/recovery: invalid credentials produce an inline, non-destructive message and the fields remain editable for retry.
• Continuation: the user proceeds to the Dashboard, or leaves for Sign Up if they have no account.

FR-10 — Role-aware access to shared bookkeeping data (required_inference) As a Small Business Owner or Accounting Staff member, I should reach only the accounting surfaces my role permits so that shared bookkeeping data is controlled appropriately.

• Trigger/input: the user navigates to the transaction list, the transaction recording workspace, or the reports surface.
• Observable result: the user reaches the surfaces their role permits and is not shown surfaces their role does not.
• Access state: protected; requires an established identity, and the role established at enrollment governs reach.
• Failure/recovery: an attempt to reach a surface outside the role's reach does not expose its data.
• Continuation: the user continues on a permitted surface.

4. User Personas

Small Business Owner

Product context. The owner runs a small business — a warung, a workshop, a small trading operation — and does the books themselves, usually on a phone, often between other work and away from any desk. There is no dedicated accountant in the picture; the owner is the bookkeeper.

Primary goal. Keep the books current without accounting training, and be able to answer "did I make money this month, and where did the cash go?" from the phone in hand.

Distinct accepted responsibilities. The owner records their own daily income and expense transactions as they happen, corrects them when they are wrong, browses them to check what has been entered, and reads the profit-and-loss and cash-flow reports for their own business. The owner is the sole authority over their own books.

Relevant inputs and decisions. For each transaction: whether it is income or expense, the amount, the date, and a description. For reporting: which period to look at, and which of the two reports answers the question at hand.

Interactions with other accepted participants. The owner works alone in the application. They do not hand work to the Accounting Staff member within the product; the two roles are distinct users of the same application, not collaborators on one another's books.

Observable success. The owner's recent transactions are visible on the dashboard, the net-position readout matches what they expect, and the profit-and-loss and cash-flow statements for the period read as trustworthy statements rather than approximations.

What makes this role different. The owner's work is self-directed and continuous: recording is a habit performed in the moment, and the report is read for the owner's own decision-making. There is no client, no handoff, and no external deadline — the pressure is simply that the books must not fall behind.

Accounting Staff

Product context. The staff member keeps books professionally, for clients, and must produce financial reports such as profit-and-loss and cash flow when they are needed. Their work is deliberate and report-driven rather than incidental.

Primary goal. Keep client books accurate and have the reports ready when they are asked for.

Distinct accepted responsibilities. The staff member records daily transactions into the books they manage, corrects entries when they are wrong, browses the recorded transactions to verify accuracy, and produces the profit-and-loss and cash-flow reports for the period in question.

Relevant inputs and decisions. For each transaction: direction, amount, date, and description, entered accurately because the report depends on it. For reporting: the period to report on and which statement is required.

Interactions with other accepted participants. The staff member works within the application on the books they manage. They do not depend on the Small Business Owner acting inside the product.

Observable success. The recorded transactions reconcile with what the staff member expects, and the profit-and-loss and cash-flow statements for the requested period are complete and ready to present.

What makes this role different. The staff member's work is accuracy-driven and report-terminated: recording is a means to a deliverable, the deliverable is a statement someone else will read, and an error is not a personal inconvenience but a wrong report. That is why the browse-and-verify step matters more in this role than in the owner's.

5. Core User Flows

Flow A — A first-time Small Business Owner begins keeping books

1. The owner opens mammoth-akuntansi on their phone and lands on Landing, anonymously. The page explains that this is a bookkeeping application for recording daily income and expenses and reading profit-and-loss and cash-flow reports, and shows a ledger object with income, expense, net, and cash rows.
2. The owner taps the solid ink call-to-action bar, "Mulai mencatat", and arrives at Sign Up.
3. On Sign Up, the owner enters their identifier and secret and selects the Small Business Owner role, then submits.
4. The account is created and the owner lands on Dashboard, now verified. The net-position readout counts up once and the cash-flow bars grow once from the baseline.
5. Because there are no transactions yet, the recent-rows region shows the ruled-ledger line diagram with a single accent tick and a prompt to record the first transaction. The owner taps through to New Transaction.
6. On New Transaction, the owner leaves the direction on income, enters the amount, keeps today's date, and types a description, then taps the save bar.
7. The transaction is saved. The owner returns to the transaction list and sees the new row with its date, description, direction, and amount.
8. Failure path: if the owner submits without an amount, an inline message marks the amount field and the entered description is preserved; the owner corrects the amount and resaves.
9. Continuation: the owner returns to Dashboard, where the net-position readout and the recent rows now reflect the recorded transaction.

Flow B — A Small Business Owner records the day's expenses and checks the month

1. The owner opens the application and verifies through Login with their credentials, landing on Dashboard.
2. The owner taps to record a new transaction and arrives at New Transaction.
3. The owner switches the direction segmented control to expense — the indicator slides and stops — enters the amount, sets the date to the day the expense occurred, and types a description, then saves.
4. The transaction is saved and appears in the transaction list. The owner repeats steps 2–3 for each remaining expense of the day.
5. Failure path: if a save fails, an inline message appears and the entered values remain in the form; the owner resaves without retyping.
6. The owner opens Transactions and narrows the list to the current month to confirm everything entered is present and correct.
7. The owner opens a row that was entered wrongly, edits its amount on New Transaction, and saves; the corrected row is visible in the list.
8. The owner opens Reports, selects profit-and-loss, and selects the month. The stepped statement shows revenue, expense, indented subtotals, and net profit with a double hairline above it.
9. The owner switches to cash flow and reads the three-band operations/investing/financing diagram with aligned figures beneath each band.
10. Continuation: the owner returns to Dashboard, where the period's net position and the recent rows match the reports just read.

Flow C — An Accounting Staff member records client transactions and produces a report

1. The staff member opens the application and verifies through Login, landing on Dashboard.
2. The staff member reviews the dashboard's period, net-position readout, income/expense pair, and cash-flow bar diagram to see the current state of the books.
3. The staff member opens Transactions and browses the recorded entries, checking dates, descriptions, directions, and amounts against what they expect.
4. Where an entry is missing, the staff member opens New Transaction, sets the direction, enters the amount, sets the date, and types a description, then saves. The new row appears in the list.
5. Where an entry is wrong, the staff member opens it from the list, corrects the field on New Transaction, and saves; the corrected row is visible in the list.
6. Failure path: if the transaction list fails to load, an inline message with a retry control appears rather than an empty list; the staff member retries and the list loads.
7. The staff member opens Reports, selects the period the client needs, and reads the profit-and-loss statement — revenue, expense, indented subtotals, net profit under a double hairline.
8. The staff member switches to cash flow and reads the three-band diagram with aligned figures beneath each band.
9. Failure path: if a report fails to compute, an inline message with retry appears rather than partial figures; the staff member retries, or changes the period and recomputes.
10. Continuation: with the statement complete for the period, the staff member returns to Dashboard or to Transactions to continue the next period's bookkeeping.

Flow D — A returning user resumes where they left off

1. The user opens the application and arrives at Landing anonymously, or navigates directly to Login.
2. On Login, the user submits their credentials.
3. Failure path: if the credentials are rejected, an inline, non-destructive message appears and the fields remain editable; the user retries, or leaves for Sign Up if they have no account.
4. On success, the user lands on Dashboard with their own durable records and reports intact, and continues recording or reporting from there.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Dieter Rams, and the headline idea is "Less, but better — a bookkeeping instrument, not an app." The register is assurance, not excitement: numbers that behave like a well-made instrument, controls honest about what they do, and a report that reads like a printed ledger rather than a dashboard toy. Warmth matters — this is someone's livelihood — so the neutrals are warm greys and off-white, never clinical blue-white.

Colour tokens — light mode (default surface).

The accent is used only for the live amount, the selected segmented-control state, negative cash-flow warnings, and the hairline under the active tab — never as a large fill, never as a button background. Income is not coloured green and expense is not coloured red: direction is carried by a + / − sign set in the accent and by position in the ledger column, so the palette stays at one accent. Dark mode is not the default surface — this instrument lives on paper.

Typography.

• Headings: Archivo, 600–700, tight tracking -0.02em. Sentence case for headlines; small-caps with +0.08em letterspacing for every section label, table header, and field label — the Braun label grammar. Headlines stay short and declarative ("Buku besar", "Laba rugi"), never conversational.
• Body: Fira Sans.
• Numbers are the display type. Amounts, totals, and report figures are set at the largest sizes on the screen, tabular, with the currency symbol one step smaller and muted.
• Scale: 1.25 modular on a 4/8-pt rhythm — 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49. Mobile hero display 40px, desktop 64px; report totals 32px mobile → 48px desktop; body 16px with 1.55 line-height; labels 12px small caps. All display sizes set with clamp(), e.g. clamp(40px, 8vw, 64px).

Shape language. Rounded-rectangle controls with a consistent 10px radius — the same radius on buttons, inputs, segmented controls, and the transaction rows' leading icon tile, so the whole app feels milled from one stock. No pills, no blobs, no 24px soft cards. 1px hairlines in #D8D2C7 do the structural work that shadows do elsewhere; only the active sheet gets a real elevation (very soft, 8% black, 24px blur). Icons are 2px-stroke geometric pictograms — arrow-down-left for income, arrow-up-right for expense — drawn on a 24px grid with squared terminals.

Layout. A strict 4-column mobile grid (8px gutters, 20px margins) and a 12-column desktop grid at 1280px, with content capped at 720px so the ledger never stretches into an unreadable band. The signature structure is the label/value row: small-caps label flush left, tabular value flush right, aligned across every screen — dashboard, transaction list, and both reports share it, so the eye learns one alignment and reads faster. Sections are separated by full-width hairlines, not cards. The Dashboard is a vertical instrument stack: period selector, one large net-position readout, a two-column income/expense pair, a compact cash-flow bar diagram, then the most recent five ledger rows. Reports are printed-document layouts — P&L as a stepped statement with indented subtotals, cash flow as a three-band diagram (operations / investing / financing) with aligned figures underneath.

Imagery. No photography and no illustration for its own sake — the imagery is the diagram. Cash-flow bands, a small monthly bar strip, and a 12-month sparkline drawn as 1.5px ink strokes on the paper ground. Empty states use a single geometric line diagram (an open ledger ruled in hairlines with one orange tick) rather than a mascot. The one photographic element allowed is a macro detail of paper texture or a machined dial bezel, used at most once on the Landing page, cropped hard to the grid.

Avoid. Blue or indigo primaries on white; any gradient, blob, or glassmorphism; pill buttons, 24px soft cards, and hover-lift tiles; green-for-income / red-for-expense colour coding; rounded friendly sans (Nunito, Poppins, Quicksand) or any system-ui/Inter/Roboto fallback for headings; mascots, spot illustration, and stock photography of people; bouncy or springy easing, parallax, and floating decorative elements; dashboard tiles arranged in an identical grid of equal-weight cards; dark mode as the default surface. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The Landing page as the front of a well-made manual.

The public entry is not a centred headline with a button. It is a full-width paper panel split into a hard 5/7 asymmetric grid:

• Left (5 columns). A stacked small-caps kicker — AKUNTANSI · BUKU BESAR · LAPORAN — then an oversized Archivo headline set flush-left at clamp(40px, 8vw, 64px) in ink, breaking across three lines, with a single 64px Braun-orange rule sitting above it. Beneath the headline, a solid ink CTA bar reading "Mulai mencatat" with a squared 10px radius and the orange arrow glyph, next to a plain text link to Login.
• Right (7 columns). An actual working ledger object: a white sheet with four real label/value rows — Pendapatan, Beban, Laba bersih, Kas — in tabular numerals, the net figure set at 48px in orange, ruled by hairlines. Presented flat: no perspective, no tilt, no float.
• Bottom edge. A full-bleed horizontal rule with three pinned instrument facts in small caps, so the first screen already reads like the front of a well-made manual.

The concept recomposes only accepted content and controls: the product explanation, the two core functions, the two identity paths, and the shape of the ledger the product produces. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The flat ledger object on the right of the 5/7 split — a white sheet with four label/value rows (Pendapatan, Beban, Laba bersih, Kas) in tabular numerals, the net figure at 48px in orange, ruled by hairlines.
• Input → transformation → outcome thesis. On first paint the hero is already composed and readable; the only transformation is the mechanical settling of the instrument — the 64px orange rule above the headline and the ledger's hairlines resolve into place in 120ms linear state changes, and the ledger object is then still. The outcome is a first frame that reads as a finished printed page, not an animation waiting to happen.
• Motion vocabulary. Instant, mechanical feedback: 120ms linear state changes; a 90ms press depression on the CTA bar (translateY(1px) plus a 4% darkening, no bounce); a segmented-control indicator that slides in 140ms with a sharp ease-out and stops dead. No hover-lift, no parallax, no float.
• Composed first frame. Paper ground #F2EFE9; kicker in small caps at +0.08em; three-line Archivo headline in #171512; the single 64px #E4570F rule above it; the white ledger sheet on the right with its four aligned rows and the orange net figure; the solid ink CTA bar and the plain text link beneath the headline; the full-bleed bottom rule with three small-caps instrument facts.
• Reduced-motion state. With prefers-reduced-motion, the hero renders in its final composed state with no settling transition: the rule, the hairlines, and the ledger rows are simply present, the CTA bar does not depress on press, and the segmented-control indicator jumps rather than slides. Nothing is hidden, cropped, or made unreadable.

Product-wide motion. One purposeful loop only: the dashboard's cash-flow bars grow from the baseline once on mount, 400ms, staggered 40ms, then never animate again. The net-position readout counts up once on first load, 500ms, then stays static. Under prefers-reduced-motion, both render at their final values immediately.

9. Non-Functional Requirements

NFR-1 — Mobile-first delivery (explicit) The application is delivered as a mobile application. Layout, controls, and type must be fully usable at a 375px viewport, and must remain coherent at 768px and 1280px.

NFR-2 — Readable text and controls stay whole (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, and the text and controls of any card stay 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. No other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. Where a direction or brief asks readable text or a control to be cropped, clipped, covered, or run off an edge, the text or control stays whole and the gesture is carried by imagery or decoration instead.

NFR-3 — Durable, participant-bound accounting state (required_inference) Recorded transactions and the reports derived from them are durable and bound to the correct participant. A user's records are not visible to another user, and a returning user resumes their own books.

NFR-4 — Role-aware access enforcement (required_inference) Access to the transaction list, the transaction recording workspace, and the reports surface is governed by the role established at enrollment. A surface outside a role's reach does not expose its data.

NFR-5 — Report trustworthiness (required_inference) The profit-and-loss and cash-flow statements are computed from the recorded transactions of the selected period. A failed computation surfaces an explicit error with retry rather than partial or fabricated figures.

NFR-6 — Motion restraint and reduced-motion support (explicit, from the creative direction) Motion is limited to 120ms linear state changes, a 90ms press depression, a 140ms segmented-control slide, one 400ms staggered cash-flow bar growth on dashboard mount, and one 500ms net-position count-up on first load. No hover-lift, no parallax, no floating decorative elements, no bouncy or springy easing. Under prefers-reduced-motion, all of these render at their final state immediately.

NFR-7 — Accessible contrast and legibility (required_inference) Ink #171512 on paper #F2EFE9 and on surface #FFFFFF meets accessible contrast for body and display text. Muted #8C857A is used for labels and captions, not for primary figures. The accent #E4570F is never the sole carrier of meaning: direction is also carried by the + / − sign and by position in the ledger column.

10. Tech Stack

No technology choices were specified by the user beyond "mobile application". The following are coherent defaults, labelled as such.

• Client: React Native for the mobile application, so that the mobile-first constraint is met natively and the shared ledger-row, segmented-control, and report-statement components can be built once. [Default — not specified by user]
• Backend: Python with FastAPI, serving the transaction and report endpoints and enforcing role-aware access. [Default — not specified by user]
• Storage: A relational database for users, transactions, and periods, with report figures computed from stored transactions rather than stored as independent totals. [Default — not specified by user]
• Packaging and deployment: Docker with docker-compose for local and single-host deployment. Kubernetes is not required by any accepted requirement and is not included. [Default — not specified by user]
• Typography: Archivo and Fira Sans, loaded as webfonts or bundled with the client. [From creative direction]

11. Assumptions and Constraints

Constraints (binding).

• The application is a mobile application; mobile-first delivery is a hard constraint.
• The first version includes the complete feature set: daily transaction recording (income and expenses) and financial reports (profit-and-loss and cash flow).
• The visual direction is authoritative: the palette, typography, shape language, layout, imagery, and motion described in Sections 6–8 are binding, and the generic indigo/blue-on-white SaaS template is forbidden.
• The two accepted personas are the Small Business Owner and the Accounting Staff member. No other human role is added.

Assumptions (narrow, labelled).

• Assumption: a transaction carries an amount, a date, a direction (income or expense), and a description. These are the fields the accepted recording and reporting behaviour requires; no further field is assumed. [required_inference]
• Assumption: the reporting period is selectable, because both accepted reports are period statements and the dashboard shows a period. [required_inference]
• Assumption: the role selected at enrollment is the role that governs access thereafter. [required_inference]
• Assumption: the application is single-currency, since no multi-currency behaviour was accepted. [Default — not specified by user]
• Assumption: the interface language follows the creative direction's Indonesian labels ("Buku besar", "Laba rugi", "Mulai mencatat"). [From creative direction]

Explicit exclusions for the current version. No invoicing, no accounts-receivable or accounts-payable aging, no inventory, no payroll, no tax filing, no bank-feed integration, no multi-currency, and no third-party accounting-provider surface. No future-horizon capability has been accepted.

12. Glossary

• Transaction — a single recorded movement of money, either income or expense, carrying an amount, a date, a direction, and a description.
• Direction — whether a transaction is income or expense. Carried visually by a + / − sign in the accent colour and by position in the ledger column, never by green/red colour coding.
• Ledger row — the application's atomic layout unit: a small-caps label flush left and a tabular value flush right, aligned identically across the dashboard, the transaction list, and both reports.
• Net position — the period's income minus its expenses, shown as the largest element on the Dashboard.
• Profit-and-loss statement — a stepped statement of revenue and expense for a period, with indented subtotals and a double hairline above net profit.
• Cash-flow statement — a three-band diagram of operations, investing, and financing for a period, with aligned figures beneath each band.
• Period — the date range a dashboard summary or a report covers.
• Small Business Owner — the accepted persona who records their own daily income and expense transactions and reads their own reports.
• Accounting Staff — the accepted persona who manages bookkeeping for clients, recording daily transactions and producing profit-and-loss and cash-flow reports.
• Role-aware access — the distinction between the Small Business Owner and the Accounting Staff member in what they may reach and act upon in shared bookkeeping data.