# A Formula Language for Financial Models > A domain-specific language connecting the fields, relationships and calculations of a financial data model. - Selected system 01 · Language Systems - Web page: https://www.softwarefoundry.ch/systems/formula-language/ **Figure 01.** A formula combines values from separate records. Illustrative calculation. - The model amount is 1,000; related record A supplies a share of 40%. - An illustrative formula multiplies those values to produce a result of 400. - The formula resolves values from separate records through the shared model vocabulary. ## What It Does The formula language lets analysts express calculations, selection rules and scenario adjustments using the vocabulary of a financial model. Formulas can refer to properties, related records and configured values, rather than the storage layout behind them. A rule can combine a record's properties with those of its parent, inspect a related collection, or use a configured value. The same model vocabulary supports interactive editing and server-side workflows. The illustrative formula resolves an amount and a share from separate model records, not from the cells displaying them. ## The Design Problem The model is not a flat spreadsheet. Some values live directly on a record; others belong to related collections or are defined through configuration. A name in a formula might resolve to one value or several. Users need a consistent language across those differences, while each operation needs the right record context. Formulas also serve different purposes. A selection rule decides whether a record belongs in a collection. An adjustment changes a field. A dependent calculation updates other values after an edit. These operations share a vocabulary without being interchangeable. ## Design Decisions ### Field resolution Field descriptors connect a named term to its location, type and relationships in the data model. Resolution can read a direct field, find an entry in a related collection, or return several values. Domain functions handle operations such as checking the status of a related record or its membership in a group. The parser works with these identifiers and function definitions, rather than embedding the application's record structure. The calling workflow supplies the model context in which an expression runs. ### Names and identifiers Analysts write with readable names. Stored expressions use consistent identifiers. The editor translates field names without changing quoted values inside an expression. Parsing produces a structured representation of operators, fields and nested function calls. The editor validates syntax, identifiers and arguments before saving; execution uses the corresponding field resolvers and function implementations. ### Formula dependencies Configured formulas declare their input and output fields. When a field changes, the formula system follows the affected dependencies and applies their calculations to the model. Editing a related collection, for example, can trigger formulas that depend on that collection. Browser edits and server-side scenario adjustments reuse this mechanism. Selection uses the expression evaluator against a record and its parent. The shared vocabulary connects these workflows while each retains its own execution rules. ### Selection queries Some selection rules identify a limited set of records to fetch before evaluating the full expression. “Record A or B, with an additional condition” permits that restriction; “record A, or anything meeting that condition” does not. The system uses this shortcut only when the expression's structure supports it. Other formulas run through the evaluator without narrowing retrieval. --- Software Foundry Sàgl, Lugano, Switzerland. To discuss a project, email [contact@softwarefoundry.ch](mailto:contact@softwarefoundry.ch?subject=A%20Formula%20Language%20for%20Financial%20Models).