Budget vs actual in Kintone, on an April fiscal year
Budget-vs-actual rarely stalls on the aggregation itself. It stalls because the sales app stores an order date while the targets app stores "FY2025" and "Q1" in dropdowns — both reasonable designs, and nothing in Kintone lines them up.
Why a date and a dropdown do not line up
The sales side carries a date per record. The targets side is naturally one row per "FY2025 sales target", with the period held as a dropdown or text. Putting a date on a target is meaningless, so both designs are correct.
Kintone has no mechanism to derive a fiscal year or quarter from a date and match it to a dropdown. So teams work around it — adding a date to the targets app, or hand-entering a fiscal-year dropdown on every sale — and both workarounds generate missing entries and quiet inconsistency.
The April fiscal year, which most tools get wrong
Most Japanese companies run an April fiscal year, which means 2026-03-31 is Q4 of FY2025 and 2026-04-01 is Q1 of FY2026. A tool that assumes a calendar year silently misplaces every record around the boundary.
The dangerous part is that nothing errors. The chart renders, the numbers appear, and the mismatch surfaces in a monthly review when a total does not agree with finance.
Deriving fiscal periods from a date
| Order date (date field) | Fiscal year | Quarter | Matches target dropdown |
|---|---|---|---|
| 2025-04-01 | FY2025 | Q1 | FY2025 / Q1 |
| 2025-05-02 | FY2025 | Q1 | FY2025 / Q1 |
| 2025-10-15 | FY2025 | Q3 | FY2025 / Q3 |
| 2026-03-31 | FY2025 | Q4 | FY2025 / Q4 |
| 2026-04-01 | FY2026 | Q1 | FY2026 / Q1 |
The fiscal start month is configurable; April is the default. January and July starts work the same way.
Three ways to build it
Option 1 — add a fiscal-year field to the sales app. Derive it from the order date with a calculated field or JavaScript. It works, but historical records need back-filling, and changing the fiscal start month means updating every record.
Option 2 — put dates on the targets app. Give each target a start and end date and match on range. Structurally clean, but it adds data entry for the finance or planning team who own that app.
Option 3 — derive at aggregation time. Leave both apps alone and let the dashboard derive year, quarter and month from the date and match them to the dropdown. No schema change, no back-fill, and changing the fiscal start month is a setting rather than a migration.
What to verify before you commit
Check three things with your own data. (1) Is the fiscal start month configurable? Some products hardcode January. (2) Can it match a date field directly against a period dropdown? If not, app changes are implied. (3) Does the boundary behave? Enter one record on 31 March and one on 1 April and confirm they land in different fiscal years — this is where tools quietly fail.
Common questions
Can Kintone do budget vs actual without a plugin?
Yes, if targets and actuals live in the same app. In practice most organisations keep them in separate apps, and Kintone's built-in graphs cannot aggregate across apps, so the comparison becomes a CSV export.
Does it work with a fiscal year that does not start in April?
Yes. In Kinplug Dashboard the fiscal start month is configurable; April is simply the default because most Japanese companies use it.
Do we have to recalculate historical records?
Not if the fiscal period is derived at aggregation time. If you instead add a fiscal-year field to the app, every existing record has to be back-filled.
What if our period labels are not "FY2025"?
Matching follows whatever values your period dropdown actually contains. If the labels are inconsistent, normalise them first — mixed conventions are the usual cause of numbers that look almost right.
A dashboard that assumes fiscal years
Kinplug Dashboard derives year, quarter and month from a date field and matches them to your targets app's period dropdown automatically. Fiscal start month configurable, April by default. No schema changes, no back-fill.